Protocol for "new" and "instanceof"?
Has an official strawman been submitted for the "extend" operator? Having trouble searching for it, but might be using the wrong terminology.
(Editorial: I love this operator)
Me, too (I also like the way it looks):
See harmony:object_literals#object_extension_literal
Sent from Samsung tabletAxel Rauschmayer <axel at rauschma.de> wrote:> Has an official strawman been submitted for the "extend" operator? Having trouble searching for it, but might be using the wrong terminology. (Editorial: I love this operator)
Me, too (I also like the way it looks).
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
In a vein similar to making [] available to collections, one could make "new" and "instanceof" available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes function ProtoExemplars() {} ProtoExamplar.prototype.{ operatorNew(...args) { let inst = Object.create(this); return inst.constructor(...args); }, operatorInstanceof(lhs) { return this.isPrototypeOf(lhs); } };
More entirely unsubstantiated personal opinion based on a few days experience:
Gonzala's Gozala/selfish does this now and with nicer syntax.
One subtle point I missed about his approach: instance (member) variables are created in initializers, not as literals, unless you intend to make the variable part of a prototype. This could be stumbling block for Java converts, who expect declarative members.
Only bump so far: XMLHttpRequest.apply fails and you can't run XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on the object. So I could not figure out how to inherit from XMLHttpRequest.
jjb
On Oct 21, 2011, at 11:49 AM, John J Barton wrote:
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer <axel at rauschma.de> wrote: In a vein similar to making [] available to collections, one could make "new" and "instanceof" available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes function ProtoExemplars() {} ProtoExamplar.prototype.{ operatorNew(...args) { let inst = Object.create(this); return inst.constructor(...args); }, operatorInstanceof(lhs) { return this.isPrototypeOf(lhs); } };
More entirely unsubstantiated personal opinion based on a few days experience:
Gonzala's Gozala/selfish does this now and with nicer syntax.
That is nice, but it seems to me Axel was aiming to make the new and instanceof operators useful. If you don't care about those operators, Irakli's library is great.
One subtle point I missed about his approach: instance (member) variables are created in initializers, not as literals, unless you intend to make the variable part of a prototype. This could be stumbling block for Java converts, who expect declarative members.
Java-heads may expect new and instanceof too, for that matter.
y bump so far: XMLHttpRequest.apply fails and you can't run XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on the object. So I could not figure out how to inherit from XMLHttpRequest.
This seems like an XHR bug. Mail public-script-coord?
(sorry for limitations of terrible tablet mailer) Also, in general this sort of well known private method name hook is much more extensible than "internal method" as currently used in the es spec. They also avoid the need to polute the Proxy API
Allen
Sent from Samsung tabletBrendan Eich <brendan at mozilla.com> wrote:On Oct 21, 2011, at 11:49 AM, John J Barton wrote:
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
In a vein similar to making [] available to collections, one could make "new" and "instanceof" available to other inheritance schemes.
For example:
// “Meta-class” for prototypes as classes/instantiable prototypes function ProtoExemplars() {} ProtoExamplar.prototype.{ operatorNew(...args) { let inst = Object.create(this); return inst.constructor(...args); }, operatorInstanceof(lhs) { return this.isPrototypeOf(lhs); } };
More entirely unsubstantiated personal opinion based on a few days experience:
Gonzala's Gozala/selfish does this now and with nicer syntax.
That is nice, but it seems to me Axel was aiming to make the new and instanceof operators useful. If you don't care about those operators, Irakli's library is great.
One subtle point I missed about his approach: instance (member) variables are created in initializers, not as literals, unless you intend to make the variable part of a prototype. This could be stumbling block for Java converts, who expect declarative members.
Java-heads may expect new and instanceof too, for that matter.
y bump so far: XMLHttpRequest.apply fails and you can't run XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on the object. So I could not figure out how to inherit from XMLHttpRequest.
This seems like an XHR bug. Mail public-script-coord?
As for xmlhttprequest not working, I get
"DOM object constructor cannot be called as a function"
This basically means xmlhttprequest is a host object which does not want to behave normally. Maybe with some very subtle tricks you can get it to subclass but I recommend not subclassing host objects.
I also have a feeling axel means defining a meta object with behaviour for instanceof and new then having every other "class-like" object inherit it as a base class.
As an aside if we allow overloading of new and instanceof, can we overload every operator?
On Oct 21, 2011 7:49 PM, "John J Barton" <johnjbarton at johnjbarton.com>
wrote:
On Fri, Oct 21, 2011 at 9:36 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
In a vein similar to...
More entirely unsubstantiated personal opinion based on a few days experience:
Gonzala's Gozala/selfish does this now and with nicer syntax.
One subtle point I missed about his approach: instance (member) variables are created in initializers, not as literals, unless you intend to make the variable part of a prototype. This could be stumbling block for Java converts, who expect declarative members.
Only bump so far: XMLHttpRequest.apply fails and you can't run XMLHttpRequest.prototype.addEventListener unless you run XMLHttpRequest() on the object. So I could not figure out how to inherit from XMLHttpRequest.
jjb
Also, in general this sort of well known private method name hook is much more extensible than "internal method" as currently used in the es spec. They also avoid the need to polute the Proxy API
Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness.
On Fri, Oct 21, 2011 at 7:08 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
Also, in general this sort of well known private method name hook is much more extensible than "internal method" as currently used in the es spec. They also avoid the need to polute the Proxy API
Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness.
Private names in basically the same form as have been accepted for ES.next are available in Racket [1], with the equivalent of the 'private x;' syntax that we proposed but didn't make the cut. I believe that the system in Racket was one of the inspirations for Dave's original private name proposal long long ago.
Thanks! Nothing surprises me about Racket. Maybe when it doesn’t have a feature. ;-)
On Oct 22, 2011, at 2:18 , Allen Wirfs-Brock wrote:
also see Smalltalk selector namespaces www.smalltalksystems.com/publications/subsys.pdf which have also been proposed for Ruby www.sapphire-lang.org/wiki/1/Selector_namespaces
Because Smalltalk selectors selectors (ie, names) can operationally be any object, sometimes newly instantiated objects are used when a guaranteed unique method selector is needed for system purposes.
Very interesting, thanks!
I find that concepts in my code are fairly stable, but their names aren’t. Completely separating the concerns of identifying a concept and naming a concept might make sense in large systems. But it obviously makes it more difficult to edit source code (no more vi...).
On 22 October 2011 01:08, Axel Rauschmayer <axel at rauschma.de> wrote:
Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness.
Dynamically generated abstract names are actually a fairly standard approach to achieve information hiding, at least in languages that cannot enforce it by other means (e.g. through a type system).
On Oct 21, 2011, at 19:08, Axel Rauschmayer wrote:
Also, in general this sort of well known private method name hook is much more extensible than "internal method" as currently used in the es spec. They also avoid the need to polute the Proxy API
Reified names (private or otherwise) are a very powerful mechanism. I’m not aware of another programming language that does this (possibly Common Lisp with its symbols, but I don’t know enough about them). It’s good to have them, because they increase JavaScript’s expressiveness.
Common Lisp symbols are definitely reified names. Since all textual source code passes through the reader, which performs symbol lookup, nearly every name-of-a-thing is a symbol. Uninterned symbols - those not found in any symbol table (package) - are fully usable as names for things but cannot be retrieved starting from only textual information.
However, there is no guarantee that something with an uninterned name cannot be found by other means, so uninterned symbols do not form a security mechanism. They are primarily used for non-conflicting names in generated code.
In a vein similar to making
[]available to collections, one could makenewandinstanceofavailable to other inheritance schemes.For example:
// ?Meta-class? for prototypes as classes/instantiable prototypes function ProtoExemplars() {} ProtoExamplar.prototype.{ operatorNew(...args) { let inst = Object.create(this); return inst.constructor(...args); }, operatorInstanceof(lhs) { return this.isPrototypeOf(lhs); } };In a vein similar to making [] available to collections, one could make "new" and "instanceof" available to other inheritance schemes. For example: // “Meta-class” for prototypes as classes/instantiable prototypes function ProtoExemplars() {} ProtoExamplar.prototype.{ operatorNew(...args) { let inst = Object.create(this); return inst.constructor(...args); }, operatorInstanceof(lhs) { return this.isPrototypeOf(lhs); } }; -- Dr. Axel Rauschmayer axel at rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com