> > 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.
>
> I think this is a canard.  Because for any class that is defined by
> the <class> tag, you can't _just_ say `new foo(...)`.  The arguments
> to the new call are both arcane and cast in stone (they are:
> parentNode, initialAttributes, childrenSpec,
> whetherToInstantiateAsynchronously).  [That is unless you are talking
> about instantiating a data node, in which case there is a different
> set of arcane arguments.]
>
> I think we fool ourselves by using the tag <class> when we really
> mean <tag> or <element>.  If we want people to be able to specify
> straight classes in LZX, we could add a tag for that, but I think the
> correct tag for that is <script> class foo { ... } </script>.
>

I agree with Tucker. The classes that we define using the <class> tag are
only useful/comprehensible when they are extensions of LzNode. When
you start allowing people to
extend arbitrary classes using the XML syntax, it rapidly becomes obvious that
you are not in Kansas anymore. It's not just the "new ..." syntax,
it's all the other goodies people will expect (<attribute> tags,
setters, constraints, event handlers), which will have explosively bad
results if anyone tries to use them.

_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Reply via email to