This expresses an issue I have as well. the es:harmony proposal for classes
just vaguely states it desugars into es5 things.
We may need more clarification on exactly what it desugars to and how you
can interact with a "class" object outside the declarative class
expressions.
On Oct 13, 2011 1:03 AM, "Allen Wirfs-Brock" <al...@wirfs-brock.com> wrote:
Alex, Erik, and I had a twitter conversation that eventually ran into the
inevitable limit of effective communications using 140 character messages.
This seems like a better place to capture and discuss the issues...
The conversation started about the new DOM API that Dart is proposing and my
question of why a new language is need to prototype such an interface. Why
not just develop it in JavaScript.
Erik mentioned that Proxies are needed and I replied that experimental
implementations are available.
Alex also mentioned that a "use strict" for the DOM is needed, but we didn't
follow up on that. I'd like to know more about what that meant.
Finally Alex said that he needs "extensible Array types" and said that "the
committee hasn't moved quickly on that" . A subsequent message clarified
that we was talking about "subclassing Array".
I said that <| supports "array subclassing" (in fact, this was the original
use case that gave rise to <|) and Alex asked to be reminded how that would
work and what about the length property.
I responded:
function createArraySubclass(proto, ...values) {
return proto <| [...values];
}
If I'd had more characters I would have said that this creates a new object
whose [[Prototype]] is proto and that the object has all the special
characteristics of an array object. In particular Object.isArray will
report true for it and the object has the special behavior of automatically
updating the length property when elements are added past the end. It
really is an array object, just one with a different [[Prototype]]. If you
want it to also inherit from Array prototype you can define proto such as:
var proto = Array.prototype <| {/* additional "subclass" methods */};
Alex respond that new and instance of didn't work.
(using new to create DOM nodes is one of the characteristics of the Dart DOM
design).
It took me three tries to get all the typos out, but I showed how new could
be made to work:
var SubArray = Array <| function(...values) {
return Object.getPrototypeOf(this) <| [...values];
}
/* add subclass methods */
SubArray.prototype.method1 = function() {...};
SubArray.prototype.method2 = function() {...};
/*or stache it: SubArray.prototoype.{method1() {..}, method2() {}}; */
then you can say:
var s = new SubArray(1,2,3);
console.log(s.length); //3
s[3] = 4;
console.log(s.length); //4
console.log(Object.isArray(s)); //true
console.log(s instanceof SubArray); // true
console.log(s instanceof Array); //true
Alex responded that the proposed class syntax
class NodeList extends Array { ... }
would also do the trick.
I respond "does class extend as proposed, propagate over-ridden [[internal
methods]]? Don't think so?"
Alex that I was being "class syntax hostile...Why the hate?" I plead
140-char terseness.
However, as I then pointed out, this is one of my issues with the class
proposals. They have never been completed to the level of specifying how
things like subclassing array should be handled. Alex apparently thought
that
class NodeList extends Array { }
would automatically mean that NodeList instances would have full array
instance semantics. I don't see how that would work. Would
class ExtendedNodeList extends NodeList { ...}
also result in a class whose instances had array instance semantics? How
about in
function makeClass(sup) {
class newClass extends sup {...};
return newClass
};
var c1 = makeClass(Array);
var c2 = makeClass(c1);
var c3 = makeClass(RegExp);
I just don't see how the class declaration would know when it did or didn't
have to create special instance objects.
On a related matter, would you define a class whose instances are Proxy
instances. The most recent discussions I followed seem to preclude using
the trick I used above for arrays, something like:
class P extends Object{
constructor () {
return Proxy.create(myHandler,Object.getPrototypeOf(this));
}
}
because they disallow explicit returns from within constructors. Even if
this was allowed what would happen for
class Q extends P {...}
Is there anyway to subclass a proxy-based class and automatically get the
proxy based behavior in the subclass instances?
We pretty much concluded with Alex asserting that the class declarations
would provide a place to hang whatever (language design) hacks are needed to
resolved such issues. And I asserted that I was more interested in making
sure we had the primitive in the language that could be sugared (by library
designers into these sorts of abstractions). Nothing new in that basic
disagreement about approach.
Something we didn't get into, was the issue of how much of existing NodeList
behavior you would really want to preserve in a new DOM design. I think that
would be another interesting discussion.
Alex and Erik may have a different perspective on this little debate and may
want to emphasize something that I glossed over. So, please do. Regardless,
I think we stirred up some potentially interesting issues.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
