On 9/27/06, Henry Minsky <[EMAIL PROTECTED]> wrote:
> > > 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.
>
I also want to point out that we have some gymnastics in the compiler
to deal with making 'new' work on LZX-defined classes , and it would
be less fragile and easier to support other platforms if we could
encourage users to use an API call to instantiate these things. If
it's done by making it fit into the DOM API, we kill two birds with
one stone, in terms of making the language comprehensible to users who
are accustomed to DHTML programming.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
