On Sep 27, 2006, at 5:32 AM, P T Withington wrote: > The incompatible change is that a tag `foo` defined using `<class > name="foo" ...` will no longer be able to be instantiated dynamically > by `new foo(...)`. Such code should be replaced by > `<parent>.makeChild(...)`. (The arguments to `new foo` and > `makeChild` are similar but different -- this is not a recipe on how > to rewrite one to the other, just a note that you will need to > rewrite.)
While I understand why this is appealing from an implementation standpoint, I have to say that this solution appears to be a step in the wrong direction. It breaks an organizing principle that makes LZX (somewhat) comprehensible -- namely, that tags and classes are one and the same. Being able to do "new foo(...)" is pretty important, especially as we try to attract JS developers. And not all tag-defined classes are visual, so they don't necessarily have a visual parent. > > This proposal will also fix the long-standing issue that the built-in > tags are implemented by classes whose name does not correspond to the > tag name. Under this proposal, all dynamic instantiation of tag > classes will be by tag name, so that issue goes away. Now this I like! For exactly the reason stated above -- clarity of mapping between tags and classes. Is there any way to work this such that we could do, say "new lz.foo (xxx)" where lz is a hypothetical namespace for built-in classes? (Then how do you declare the class/tag? more work, more work) _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
