I remember having a discussion with this whole topic with Oliver
Steele in the summer of 2003, when I asked him if <foo> and "new foo
(...)" were just mirror implementations of the same thing.
And he said, "Yes." And then he added with that patented Oliver wry
twist "But they are crazy funhouse mirrors."
There are places in the Dguide where I explain that a <view> is an
LzView, but if you define your own class with the <class> tag you get
a thing that does not have the "Lz" in front of it.
The doctools are a concern. If we make Tucker's suggested change, do
the tools still "just work"?
As I said, in general, this sound like a good direction to go and now
seems like a good time to make a change, if we're going to make one.
But my spidey senses are telling me that there are big documentation
issues lurking here. Of course my spidey senses are not infallible,
but nevertheless, they are tingling.
jrs
On Sep 27, 2006, at 1:48 PM, Henry Minsky wrote:
> 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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
