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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
