On Oct 16, 2011, at 12:51 PM, Axel Rauschmayer wrote:
>> From: Allen Wirfs-Brock <[email protected]>
>> Subject: Re: new <Object>
>> Date: October 11, 2011 23:50:14 GMT+02:00
>> To: Jake Verbaten <[email protected]>
>> Cc: es-discuss <[email protected]>
>>
>> It's still on my radar. Most recently see
>> https://mail.mozilla.org/pipermail/es-discuss/2011-September/016736.html
>>
>> It isn't an accepted Es.next proposal, but I suspect there is wiggle room
>> for it to slip in as part of the enhanced object literals/class support if
>> there is sufficient interest.
>>
>> I haven't pushed it too hard yet because I think we have more pressing
>> issues to get resolved and I didn't want this to become a distraction.
>> However, I probably should write up a strawman for it.
>
>
> A few ideas, also in the vein of “not wanting this to be a distraction”:
>
> - I would feel better about “instantiable prototypes” (IPs) if there was a
> clean migration path. Then people could start using IPs and it wouldn’t
> matter whether the standard classes were constructors or IPs. See check list,
> below.
> - What will happen to class methods? That’s the only advantage that
> constructors currently have. But I’ve always felt uneasy about them (they
> felt to Java-ish where they are used to mimic functions). I suspect that most
> of these methods are better put into a module (especially Object.*).
Self seems go get along fine without them. It it's case functions that you
might assign to a class method (constants, alternative factories) are just
instance methods on the IP.
> - Wish – factory methods that can return subclasses. Not sure how that fits
> into the picture; it’s possible that using a function is fine as a
> work-around.
they can, just use
new this;
within such factories. Example using a fExemplar:
let Klass = function () {
/* normal constructor */
this.iamAKlass = true;
}.constructor.{
prepared() {
preprocessArguments(args);
instance = new this();
this.prepareInstance(instance);
return instance;
},
prepareInstance(obj) {
obj.iamPrepared = true;
}
};
let SubKlass = Klass <| function () {
super.constructor();
this.iamASubKlass = true;
};
let k = new Klass;
k.hasOwnProperty('iamAKlass'); //true
k.hasOwnProperty('iamPrepared'); //false
let pk = Klass.prepared();
pk.hasOwnProperty('iamAKlass'); //true
pk.hasOwnProperty('iamPrepared'); //true
let s = new SubKlass;
s.hasOwnProperty('iamAKlass'); //true
s.hasOwnProperty('iamASubKlass'); //true
s.hasOwnProperty('iamPrepared'); //false
let ps = SubKlass.prepared();
ps.hasOwnProperty('iamAKlass'); //true
ps.hasOwnProperty('iamASubKlass'); //true
ps.hasOwnProperty('iamPrepared'); //false
> - Wish – named constructors. For that, it would be nice if we could have
> syntactic sugar such as
> new Point.zero()
> meaning that Point is just instantiated and then zero() initializes it.
> With that notation, new Point(...) actually means
> new Point.constructor(…)
> I know that this would wreak havoc with legacy compatibility, but maybe
> there is a similar solution that would not.
>
let Klass = function (arg) {
this.state = arg;
}.constructor.{
zero() {
return new this(0)
}
}
};
let k = Klass.zero();
let SubKlass = Klass <| functiion(arg) {super.constructor(arg)};
let s = SubKlass.zero();
s.state; //0
s instanceof SubKlass; //true
(BTW, all of the above is just new skin on old Smalltalk patterns where this
style of class methods are old hat)
>
> Check list of mechanisms that need to generic.
> - “new” works the same for IPs and constructors.
> - “instanceof” needs a similarly generic definition.
> - Subclassing. There is no need to let a constructor “subclass” a prototype,
> but the inverse should be doable. Then <| won’t work. Instead, maybe a method
> that is used in both cases?
I don't agree. If you are going to have multiple kinds of named exemplars (and
we already do) then the kind of exemplar is one of the things that you will
generally want to abstract away in normal usage. Consider an exemplar E. The
choice of exemplar style of E was an implementation decision that shouldn't be
visible to users of E. I shouldn't have to know what kind of exemplar it is in
order to specialize it. E <| anyExempalr should work regardless of how E was
implemented.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
