On 2009-11-17, at 10:55, Rami Ojares / AMG Oy wrote: > > The model of node inheritance is that you get a union of all the nodes, > > rather than overriding. > > I can see what you are getting at, but that would be a huge change in the > > language. > > I think we would have to have some really compelling use cases to consider > > that level of change. > > I totally agree. > > I was thinking of implementing partially the node override in "userspace" > like this [...] > <mixin name="replaceable"> > Overrides the createChildren where it looks for immediate children with > name replace. > From it, it retrieves path attribute and using the path replaces the child > matching the path with the children of > replace. And finally removes the replace child. > </mixin> > > This feature can not be achieved with extendable/extend tags because I can > not extend some arbitrary node instance. > > What do you think?
I think you could do something like this. But, I think it might be better to demonstrate some use cases first. If this looks like something that will help people write better components, then we should think about how to make it part of the base system. I'm all for adding enabling technology to the core. There is already a "placement" mechanism that has the ability to put a child node of a class in a particular spot in the classes subview heirarchy. You might want to explore that a little. Perhaps that could be extended to become a "re-placement" mechanism too, if you actually need to replace one node with another. [Read about placement here: http://bit.ly/2HmjrS].
