> First let me write the above example in the syntax with
> implicit inheritance (no EXTENDS, inherit from first node):
>
> CLASS HatRobot [ exposedField SFFloat size 1. ]
> { Robot { children [ SUPER.children D{} ] }
> }
>
> Let's consider the following three possible definitions:
>
> 1) Robot { }
> 2) Robot { children D{} }
> 3) Robot { children [ SUPER.children D{} ] }
> 4) Robot { children Transform { children SUPER.children } }
>
> In 1) the new class inherits the value of its superclass
> for the field children.
> In 2) the new class overwrites the value inherited from
> its superclass.
> In 3) the inherited value is overwritten, but its we use
> the inherited value within the new value.
> In 4) same as 3)
>
Thanks for the explanation! This is what I needed to know.
> >
> > Here is my attempt at understanding this... it looks like you are trying
> > to specify how to change data members during inheritance. And that the
> > default is that they don't get inherited.
>
> No, the default is, that they get inherited !!!
Yes, I can see this now... but there is an option I expected to see,
which is:
> 2) Robot { children D{} }
> In 2) the new class overwrites the value inherited from
> its superclass.
In this case, the children field is not inherited. I expected to see
another possible way to interpret this case:
5) Robot { children D{} }
In 5) the new class inherits children from its superclass and adds
child "D" to this list
This is only an option for MF fields, and it is inconsistent from how SF
fields have to be handled. But then 3&4 only apply to MF fields, so
from that point of view, the two (SF & MF) are already handled
inconsistently.
The other reason I expected to see an option 5 is that it seems like it
would be reasonable in practice. But really since the MF fields are
sort of "buckets of objects", its hard to say what they are in
practice. Maybe its the MF fields that need more work.
Thanks
JJ