I don't think you read the whole revised proposal.
I responded to your earlier comments on this by proposing to continue
supporting `new <tagname>` (when the tagname does not collide with a
browser global), with a deprecation warning telling you to use `new
lz.<tagname>` instead.
Personally, I feel that `createElement('<tagname>')` will be more
intuitive to the newbie, if they are coming from DHTML, and that `new
lz.<tagname>` is more advanced, but both will be supported.
I do think that we confuse people by using <class> to define new DOM
element types. <class> is not like class: it defines a class that
_must_ be a subclass of LZNode, it must obey the node protocols, and
it is meant to be a DOM element. I think if we rename it to
<element> it will clarify that the classes that implement elements
are more specific than a general Javascript class.
On 2006-09-27, at 21:45 EDT, David Temkin wrote:
> We've absolutely got to keep our eye on learnability, and this
> proposal, I think, is problematic in that regard. We're all hoping
> for a lot of new developers once Legals is released. And that
> requires paying attention to the conceptual simplicity of the system.
>
> I've always been bothered by the view/LzView disjunction. This
> proposal fixes that, but is a step backward in another way.
>
> From a newbie point of view, "class" and "<class>" are pretty much
> the same thing.
>
> They're objects that can be instantiated, have methods, inherit
> from other classes, etc. It is just plain confusing to have to
> learn about the differences between the two, and put them in
> different mental categories. Yes, you can get more features by
> declaring a class in LZX vs. in script (attributes, constraints),
> but that's a-OK. It's still a class in the ordinary sense of the
> term -- that is the fact.
>
> To the extent that these two notions of class deviate, they need to
> be brought closer together, not separated out into two very similar
> but differently named concepts.
>
> As for the proximate issue (instantiation), why can't we have the
> "new" operator first search for the class name in the
> "ConstructorMap" and then, if there is no entry there, look for a
> global of that name? That does lead to the issue of how you
> actually would instantiate a browser-native window (masked by an
> entry in lz), but that I think is of lesser importance in this
> context.
>
> Later, we could transition to something like
>
> <class name="lz:window"....>
>
> which might be instantiated procedurally as
>
> new lz.window(xxx)
>
> And lz could be set up as the default namespace in an LZX document.
>
> - D.
>
>
>
>
>
> On Sep 27, 2006, at 4:37 PM, P T Withington wrote:
>
>> [Revised after feedback on #laszlo]
>>
>> PROPOSAL
>>
>> Currently, when you define a new class using the <class> tag, it
>> defines a global var of the same name. We propose to no longer
>> define the global. Rather, the created class will be stored in a
>> table (`ConstructorMap`, which will be aliased as `lz`) which will
>> map tag names to the class that implements the tag.
>>
>> As a part of this proposal, we will move LzNode.createElement and the
>> other DOM-like API's from incubator/domapi.js to supported public
>> interfaces and document createElement as the preferred way to
>> dynamically instantiate a tag class.
>>
>> Finally, we will rename the <class> tag to <element> to more directly
>> reflect that its purpose is to define a new LXZ DOM element (tag),
>> not to define a Javascript 2 class. To define a Javascript 2 class
>> in LZX use `<script> class foo { ... } </script>`.
>>
>> IMPACT
>>
>> User-defined elements whose name conflicts with already-defined
>> global names will generate a warning at runtime and will not create a
>> global definition (they will be entered in ConstructorMap/lz and work
>> properly as tags, but you will not be able to use `new <tagname>` to
>> instantiate them).
>>
>> Dynamically instantiating a DOM element using `new <tagname>(...)`
>> will generate a deprecated warning at runtime in debug mode. This
>> warning can be silenced by instead using `new lz.<tagname>(...)` or
>> _preferably_ `<parent>.createElement('<tagname>', ...)`. (The
>> arguments to `new lz.<tagname>` and `createElement` 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.)
>>
>> Defining a new DOM element using `<class name="foo" ...` will
>> generate a deprecated warning at compile time. This warning can be
>> silenced by replacing `class` with `element`.
>>
>> BENEFITS
>>
>> This proposal addresses [Dynamic instantiation needs better API]
>> (http://www.openlaszlo.org/jira/browse/LPP-767) by legitimizing the
>> use of LzNode.createElement as the preferred method of dynamically
>> instantiating LZX elements. This will be a change to [Creating
>> objects from script](http://www.openlaszlo.org/lps-latest/docs/guide/
>> introductory-classes.html#d0e13841) and [Instantiating classes
>> through script](http://www.openlaszlo.org/lps-latest/docs/guide/
>> class-
>> inheritance.html#d0e17585) -- which probably should be just one entry
>> rather than two.
>>
>> 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.
>>
>> This proposal will also fix [Defining a user class named `top` breaks
>> DHTML in Safari](http://www.openlaszlo.org/jira/browse/LPP-2757) by
>> removing tag classes from the global namespace. It would give us the
>> opportunity to unwind the kludge used to fix [Support with <grid> and
>> <menubar> issues](http://www.openlaszlo.org/jira/browse/LPP-775).
>>
>> SUMMARY
>>
>> I plan to implement all but the class->element transformation for
>> Legal's PR4 as the solution to LPP-2757, which is blocking several of
>> the demos.
>>
>> Speak now, if you object.
>>
>>
>> _______________________________________________
>> 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
