Design principles for extending ES object abstractions

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jul 8 18:38:33 PDT 2011


On Jul 8, 2011, at 6:03 PM, Brendan Eich wrote:

> On Jul 8, 2011, at 5:48 PM, Allen Wirfs-Brock wrote:
> 
>> On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
>> 
>>> What's the imperative API for <| (which has the syntactic property that it operators on newborns on the right, and cannot mutate the [[Prototype]] of an object that was already created and perhaps used with its original [[Prototype]] chain)?
>> 
>> Fair point and one I was already thinking about :-)
>> 
>> For regular objects, it is Object.create.
>> 
>> For special built-in object with literal forms, I've previously argument that  <| can be used to implement an imperative API:
>> 
>> Array.create = function (proto,members) {
>>    let obj = proto <| {};
>>    Object.defineProperties(obj,members);
>>     return obj;
>> }
> 
> And likewise for Function.create and RegExp.create. Boolean, Number, String, and Date get nothing :-P.

Actually in the <| proposal I define it to work with boolean, number, and string literals on the LHS.  Sorta useless but I included them so the complete set of literals was covered.  So it really is only Date that didn't get invited to the party.
> 
> We have a somewhat-troubled proposal in Harmony to make Function.create an alternative Function constructor that takes a leading name parameter, and then parameters and body string parameters. But perhaps that could be renamed Function.createNamed.

I think that create methods on Constructors should generally follow the argument pattern of Object.create.  Things that don't should get a different name. 

> 
> 
>> Basically, <| is sorta half imperative operator, half declaration component.
>> 
>> This may be good enough.  It would be nice it it was and we didn't have to have additional procedural APIs for constructing instances of the built-ins.  Somebody has already pointed out <| won't work for built-in Date objects because they lack a literal form. I think the best solution for that is to actually reify access to a Date object's timevalue by making it a private named property.
> 
> That is an old idea I've brought up from time to time. If that private name were exported, you could even make useful Date subclasses (rather than Date instances that have extended proto chains).
> 
> 
>>  BTW, way did ES1(?) worry about allowing for alternative internal timevalue representations?  If in really there really any perf issues that involve whether or not the timevalue is represented as a double or something else?
> 
> The extrapolated Gregorian calendar's range in milliseconds was chosen carefully to fit in an IEEE 754 double without loss of precision.
> 
> Real implementations decode the double into commonly-accessed fields that would have to track any updates to the milliseconds since (negative for before) the epoch.

Seems like this could be an invisible implementation detail.  An it is really worth the effort. How often does anybody set Date components in a situation that is so time critical that this would matter.  (any shouldn't dates be immutable...oh well)

Allen




More information about the es-discuss mailing list