2nd day meeting comments on the latest i18n API proposal

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Jan 20 09:14:40 PST 2011


Wait...

The whole point of the derive method was for the new object to have the former object as its direct [[Prototype]] so they could share common state.  That is lost in what is proposed below.
Also, the state of an object is not necessarily wholly  reflected by the options that are passed in when it is created.  Using Object.defineProperty as an example the property descriptor is analyzed in association with the current state of the property that is being defined.  If a descriptor does not explicit include one of its options and the property does not exist it is given a default state.  But if the property already exists and the descriptor does not explicitly include one of the options then the current state of the corresponding property attribute is keep unchanged.

In general, after one of these objects is created. the state of the object is inrepresented by its property values, not by the set of option values that were used to create it.  There is not necessarily a 1::1 correspondence between the two.  While there may be some small value in keeping track of the original options parameter value (for debugging??) there are actual hazards and costs to this.  Would you save the actual option object or a copy?  (It better be a copy, who knows what the caller is doing with it).  What about its prototype chain from which it may be inheriting option values? How do you copy it.  Do you get a fresh copy each time it is access?? Etc.  Overall, I'm not sure it is worth trying to retain.  We certainly don't do so for property descriptors.

While I don't like the nam "derive", I think this pattern is very true to the core nature of JavaScript.  It is using prototype inherence the way god and Ungar originally intended it. As an alternative to the name "derive" I would consider "new":

var loc= LocaleInfo();  //get default value
print(loc.currency);  //"EUR"  (whatever the Euro code is...)
print(loc.currencySymbol);  //€  
var loc2=loc.new({preferredCurreny: :"USD"});
print(loc.currency);  //"USD"  (whatever the Euro code is...)
print(loc.currencySymbol);  //$

(the above is just a hypothethical example and isn't actually proposing anything about the actual properties of a LocaleInfo))  




On Jan 19, 2011, at 9:37 PM, Erik Arvidsson wrote:

> On Wed, Jan 19, 2011 at 20:23, Mark S. Miller <erights at google.com> wrote:
>> On Wed, Jan 19, 2011 at 5:02 PM, Nebojša Ćirić <cira at google.com> wrote:
>>> 
>>> Eric proposed to remove the derive method from all API objects and do
>>> something like this:
>>> var loc = new LocaleInfo({....});  // {...} are the options we construct
>>> LocaleInfo object with.
>>> var opt2 = loc.options;  // This returns a copy of options from loc
>>> object.
>>> opt2.currency = "USD";
>>> var loc2 = new LocaleInfo(opt2);
>> 
>> The above code does suggest that the assignment is changing the options that
>> are stored at loc.options. That is of course not the intention. Either it
>> should give a fresh mutable copy on each request or it should give frozen
>> options object. The first was intended. On reflection, I think it would be
>> clearer if options were obtained using a method call such as "loc.options()"
>> rather than using an accessor with non-storage semantics.
> 
> I agree that having a method that returns a copy of the options is clearer.
> 
> -- 
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list