Design principles for extending ES object abstractions

Brendan Eich brendan at mozilla.com
Fri Jul 8 19:47:31 PDT 2011


On Jul 8, 2011, at 6:38 PM, Allen Wirfs-Brock wrote:

>> 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.

For ES4 we entertained date literals based ISO 8601 "T" literals. Couldn't justify 'em, the use-cases were all unlikely hardcodings.


>> 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. 

Agreed.


>> 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.

Certainly, it is invisible.


>  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)

SunSpider, cough.

/be


More information about the es-discuss mailing list