> Hope that is helpful.
Sure was. Loud'n'Clear!
But I don't think it is much more complex in the first pass to let the
xml parser go into arbitrary depths and then keep creating those classes
once encountered.
Then again I didn't write the compiler.
> Are there things you would want a local class to do that cannot be
done by a top-level class or just extending an instance?
Like so often I already found another way to do my use-case, so
currently I don't need the feature.
The need had to do with componentization, but your story does make sense
so let's just forget about it for now.
Currently I am wondering could I have multiple mixins for a class.
<class name="jee" with="foo, bar, snafu"/>
which led me to even trickier thoughts
When inheriting you can override methods and attributes.
But would be great if one could override nodes too.
This would be name based
<class name="A">
<node name="foo" attr="1">
<node name="hoo"/>
</node>
<node name="bar" attr="2"/>
</class>
<class name="B" extends="A">
<node name="foo" attr="3"/>
</class>
Now B would have structure
<node name="foo" attr="3"/>
<node name="bar" attr="2"/>
And further
<class name="B" extends="A">
<node name="foo.hoo">
<node name="haa"/>
</node>
</class>
Now B would have structure
<node name="foo" attr="1">
<node name="hoo">
<node name="haa"/>
</node>
</node>
<node name="bar" attr="2"/>
I can imagine what kind of a can of worms this would open but I can
assure you that if it would be possible it would make a difference when
designing reusable components.
Just food for thought.
And finally a concrete question:
Who overrides who when using mixins
My own guess
Primary: class itself
Secondary: all parent classes in order of proximity
Tertiary: mixin
Que?
- rami
