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
