Re: struct experts?

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

Thank you very much for your answer.

On 19 Apr 2000, Mikael Djurfeldt wrote:

> > * Why does every _instance_ of a struct hold a setter field?  wouldn't a
> >   single setter field for the corresponding struct type be enough?
> 
> Firstly, structs are not divided into classes and instances.  Structs
> are symmetric in this respect: The thing corresponding to classes is
> called "vtable".  Every struct can be a vtable for some other struct,
> including itself.  (The difference between this situation and GOOPS is
> that every GOOPS instance *can't* be a class for another instance; in
> GOOPS, classes and instances usually have different structure.)
[...]
> > * What is the meaning of the 'user' fields of a vtable?  In struct.h there
> >   is an identifier scm_vtable_offset_user defined.
> 
> Fields at scm_vtable_offset_user are user defined, lower indices are
> defined (and required) by the system.

If I understand correctly, it is actually not _every_ struct, that can be
a vtable of another struct, but a struct that is to be used as a vtable
must hold those required fields?  This was also my impression when looking
into the code.

The consequence is, that despite the 'symmetry', structs that are to be
used as vtables have to be specially designed, taking the system
requirements into account.

> > * Why does every _instance_ of a struct hold a destructor field?  Again,
> >   one destructor for the struct type should be enough.
> 
> The destructor in struct V describes how to destroy structs which have
> V as vtable.  The symmetry of structs demands that all structs have
> destructors, since, at any time, the user can use the "instance" as
> vtable.

Again, if my above statement is true, not _every_ struct can be used as a
vtable.  Only those structs, that hold the four required fields (layout,
vcell, vtable and printer) can be used as vtables.  Thus my question:  Why
is the 'free' entry not part of the required fields of the vtable?

Structs that are not to be used as vtables for other structs don't have to
provide the fields (layout, vcell, vtable and printer) and they also don't
have to provide a free function.  Thus, I don't see the conceptual
difference between the four required functions and free, and I don't see
why _all_ structs have to hold a free function, even if they will never or
(if they lack the required fields) _can_ never become a vtable.

> Regarding your question: It is not true that every "instance" hold a
> setter field.  Only "entities" hold a setter field.
> 
> GOOPS supports two kinds of funcallable instances: <operator> and
> <entity>.  For <operator>s, the procedure and setter are stored in the
> class.  For <entity>s, they are stored in the instance.  Since GOOPS
> is based on structs, I've added support for both kinds to structs.

Regarding operators, I understand that:  The vtable-vtable of operators
holds (in addition to the four required fields) the entries procedure and
setter.

> It is important to note that the class of an <operator> can itself be
> an <entity>.  (I originally thought I was crazy building in support
> for this, but then the need arose in one of my applications!)

Hmmm, maybe I now understand the problem, why the procedure and setter
fields are not part of the layout of the entity:  Making procedure and
setter fields part of the normal data fields of the entity would probably
require to put them at the beginning of the data field.  However, if an
entity was the class of an operator, the first four fields of the entity
would have to be used for the required vtable fields, right?

Thus, a different implementation alternative would have been to provide
two different layouts for entities:  One for entities that are not
intended to be used as vtables, and one for entities that also may be used
for vtables?

> > * What is the reason that the car element of a struct points to the vtable
> >   _data_ rather than the vtable?  It may be a performance consideration,
> >   but it complicates the code a lot and I wonder if it is really such a
> >   common operation to access the vtable data.
> 
> The vtable data is accessed all the time: in GC and when deciding how
> to access a slot.

Right, but in the meantime I have come to the conclusion that the reason
is a different one:  The unfortunate similarity between glocs and structs
_requires_ that the second field of a struct (the 'vcell' field) be
zero.  It is simply not possible to have the car of the struct contain the
vtable itself, because otherwise the distinction would not be possible any
more.  This vcell field, however, does not hold any additional useful
information, but it has to be accessed every time something with the
struct is to be done, just to make sure it is really a struct.  I assume,
that the additional indirection which would be necessary when the vtable
was stored instead of the pointer to the data would not cost more than the
current solution, where the vcell field has to be checked all the time.

> Hope this makes some thing clearer,

Yes, thank you very much again.  However, as you see, there are still
some open questions.  Please believe me that I don't mean to criticize any
implementation decisions that were taken, but to get a better
understanding of how structs work and how GOOPS interacts with them.

Best regards
Dirk Herrmann