I agree we should have consistent behavior across runtimes. What I can't tell is which is the "right" behavior. It seems the designer may have anticipated that a view might not have a view as a parent. The code in <view> is written in an ambiguous way: it could either be correct to signal an error when a view's parent is not a view, or it could be correct that a view not attempt to add itself as a subview to a parent that is not a view. There is a separate subnodes array that it will be added to.
Interestingly, André gave a use case for views with only a node as a parent just the other day: one might want to have a set of views that are pre-built, but not displayed, that you add dynamically to one view or another. When they are not in a view, when you don't want them displayed, a natural place to keep them might be as a subview of a node. On 2011-01-28, at 13:57, Raju Bitter wrote: > I agree with what you are saying, Tucker. That the mixin/class > authors should now what they are doing. And I understand what André is > saying, and the reasons for that.But having consistent behavior across > runtimes would be good. > > At the same time, wouldn't it be good to spit out a warning, so people > who don't know LZX that well get hinted at the mistake they are > making?
