Re: Jan 20 meeting notes
On Thu, Jan 20, 2011 at 8:25 PM, Brendan Eich bren...@mozilla.com wrote: This is the killer for me. Do not want to change === and require all-paths runtime test coverage to migrate code into Harmony. You're bang-on about the end user impact of this change - I would not be able to migrate any ES5 code to Harmony without full-on testing (not just automated regression tests), meaning Harmony uptake would be slowed, particularly in environments like mine where it is most cost effective to pick a language version and use it across all platforms (we are heavily invested in ES, and not just on the browser). Changing the semantics of an existing language feature smarts: I got bit pretty hard as a relatively new JS developer with JavaScript 1.2 and am still wincing. Of course, this is a much smaller change, but we have much more code nowadays.. :) Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Fwd: On ES Harmony proxies extensibility
Hi David, I'm forwarding your message to es-discuss as it has no direct
relevance to ES5 per se.
All, please reply only on es-discuss.
-- Forwarded message --
From: David Bruant bru...@enseirb-matmeca.fr
Date: Fri, Jan 21, 2011 at 3:08 AM
Subject: On ES Harmony proxies extensibility
To: es5-disc...@mozilla.org
Hi,
Working on writing the MDN doc for ES Harmony proxies (
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy),
I've studied the proxies and would like to provide some feedback.
My main concern in the proposal (and its current implementation on FF4b9) is
the following sentence: handler is an object that at minimum implements the
following API (7 functions). At first, I didn't understand why and then I
have tried the following :
var p = Proxy.create({get: function(proxy, name) {
return 'Hello '+ name;
}
});
Object.defineProperty(p, 'a',{value:1});
In FF4b9, this code triggers an error : defineProperty is not a function.
I interpret this as: the proxy traps the defineProperty call, then calls
handler.defineProperty which is undefined.
It gets a bit more weird when a derived trap is called. If undefined in the
handler, the default behavior is called. This behavior uses one of the
fundamental trap (by definition of derived trap). If this fundamental trap
isn't implemented in the handler, an error is thrown about the fundamental
trap which is not very intuitive. This is more of an implementation concern,
but it could be given as an advice for future implementation.
Since proxies trap all traps (fundamental and derived), all fundamental
traps need a handler method. I think that it can be the cause of a problem
for the Proxy standard extensibility:
Let's assume that, at some point, the Proxy proposal gets standardized. It
will have a well-defined set of fundamental traps and of derived traps.
People are going to write applications with them.They are going to implement
the 7 fundamental traps. This is code in the wild.
Let's assume (and this assumption is the one to discuss, I think) that the
TC-39 comittee wishes to extend the number of fundamental traps with a
fundamental trap 'FT'. This wish won't be able to be fulfilled, because
proxies will be already implemented and used. These proxies handler will
implement the 7 fundamental traps (not the 8th one) and consequently
executed on an ES engine with support of the 8th trap, it will trigger some
sort of error (FT is not a function) each time the behavior trapped by FT
happens.
Potentially breaking existing code, adding FT will be impossible.
My point is that as soon as Proxies will be standardized, it will become
impossible to add fundamental traps without either breaking existing code or
becoming inconsistent.
In my opinion, the extensibility problem is due to the fact that all traps
are trapped by default in proxies regardless if the user wants it or not.
Please allow me an analogy with DOM events. I see proxy traps as events on
ECMAScript objects. When in the code a delete happens, a /delete/ event
happens, it is trapped and the delete handler function is called like a
event handler for a DOMEventListener.
Capturing all events by default and forcing proxy authors to implement all
event handlers would be the equivalent to say to web authors implement
handlers for all DOM events for all DOM node. The scale is different, so it
sounds really ridiculous this way, but the result is the same with the
current proxy default behavior. And as this behavior prevent Proxy
extension, it would prevent addition of new DOMEvent if this had been the
chosen model at the time.
Another problem I see from the proxy author point of view is that proxies as
they are allow some non-intuitive code writing. When I started to write the
handler with just a 'get' method, I expected the proxy to only capture,
trap only get code (proxy.property) like a lot of examples (in proxy
presentation slides (http://www.slideshare.net/BrendanEich/metaprog-5303821)
or in Tom Van Cutsem tutorial (http://soft.vub.ac.be/~tvcutsem/proxies/))
seemed to imply (that's at least how I was interpreting them).
A potential last problem that goes with trapping everything by default is
performance. If we had the potential to only trap events we've registered
for (by explicitely providing a function), other events wouldn't be
trapped and thus, there could be no need to check if there is a function,
etc.
In my opinion, the solution to solve the extensibility problem, the
non-intuitive code problem and the potential performance problem would be to
only trap events that have explicitely a function for it. If there is no
function, instead of providing a default behavior, the event could just not
be trapped.
I am new on this mailing-list. I hope it was the right place to provide this
feedback.
Thanks for reading,
David
Re: Jan 20 meeting notes
On Fri, Jan 21, 2011 at 6:09 AM, Wes Garland w...@page.ca wrote: On Thu, Jan 20, 2011 at 8:25 PM, Brendan Eich bren...@mozilla.com wrote: This is the killer for me. Do not want to change === and require all-paths runtime test coverage to migrate code into Harmony. You're bang-on about the end user impact of this change - I would not be able to migrate any ES5 code to Harmony without full-on testing (not just automated regression tests), meaning Harmony uptake would be slowed, particularly in environments like mine where it is most cost effective to pick a language version and use it across all platforms (we are heavily invested in ES, and not just on the browser). No argument. In further discussion at the meeting, we also jointly concluded not to change === and to stick with a separate new eqal operation, spelling and syntax to be decided. Changing the semantics of an existing language feature smarts: I got bit pretty hard as a relatively new JS developer with JavaScript 1.2 and am still wincing. Of course, this is a much smaller change, but we have much more code nowadays.. :) Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 tel:+16135422787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On ES Harmony proxies extensibility
Hi David,
What does exactly not be trapped mean? If you define a property on a proxy
object, the defineProperty trap of the handler is the only method with which
that operation can succeed. If defineProperty doesn't exist you want us to just
ignore the operation?
I think this approach has some pretty several problems. If a programmer writes
down 6 of the 7 mandatory traps and forgets one, it will be very hard to debug
why the proxy doesn't work as expected. Corresponding operations just
disappearing in a black hole is not very intuitive.
I am not completely dismissing your concerns. We are using proxies internally
in Firefox and most people I have seen use them for the first time make exactly
the mistake your code does below: not implement all the mandatory traps. The
resulting error messages are not very intuitive, but they are a reflection of
the language semantics behind the scene.
For some specific reasons Mark can explain better than me the spec doesn't want
the implementation to verify the existence of all 7 mandatory traps, so thats
not really an option either.
We have previously discussed adding standard handlers to the specification,
i.e. an NoopHandler and a ForwardingHandler. You can delegate to these from
your handler to get the desired default behavior. I think this is the best of
the someone poor choices we have. It catches accidental trap omissions, but
still allows you to leave them out as long you pick a default behavior (and it
doesn't force a specific default behavior down people's throat).
Andreas
On Jan 21, 2011, at 8:43 AM, Mark S. Miller wrote:
Hi David, I'm forwarding your message to es-discuss as it has no direct
relevance to ES5 per se.
All, please reply only on es-discuss.
-- Forwarded message --
From: David Bruant bru...@enseirb-matmeca.fr
Date: Fri, Jan 21, 2011 at 3:08 AM
Subject: On ES Harmony proxies extensibility
To: es5-disc...@mozilla.org
Hi,
Working on writing the MDN doc for ES Harmony proxies
(https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy),
I've studied the proxies and would like to provide some feedback.
My main concern in the proposal (and its current implementation on FF4b9) is
the following sentence: handler is an object that at minimum implements the
following API (7 functions). At first, I didn't understand why and then I
have tried the following :
var p = Proxy.create({get: function(proxy, name) {
return 'Hello '+ name;
}
});
Object.defineProperty(p, 'a',{value:1});
In FF4b9, this code triggers an error : defineProperty is not a function. I
interpret this as: the proxy traps the defineProperty call, then calls
handler.defineProperty which is undefined.
It gets a bit more weird when a derived trap is called. If undefined in the
handler, the default behavior is called. This behavior uses one of the
fundamental trap (by definition of derived trap). If this fundamental trap
isn't implemented in the handler, an error is thrown about the fundamental
trap which is not very intuitive. This is more of an implementation concern,
but it could be given as an advice for future implementation.
Since proxies trap all traps (fundamental and derived), all fundamental
traps need a handler method. I think that it can be the cause of a problem
for the Proxy standard extensibility:
Let's assume that, at some point, the Proxy proposal gets standardized. It
will have a well-defined set of fundamental traps and of derived traps.
People are going to write applications with them.They are going to implement
the 7 fundamental traps. This is code in the wild.
Let's assume (and this assumption is the one to discuss, I think) that the
TC-39 comittee wishes to extend the number of fundamental traps with a
fundamental trap 'FT'. This wish won't be able to be fulfilled, because
proxies will be already implemented and used. These proxies handler will
implement the 7 fundamental traps (not the 8th one) and consequently executed
on an ES engine with support of the 8th trap, it will trigger some sort of
error (FT is not a function) each time the behavior trapped by FT happens.
Potentially breaking existing code, adding FT will be impossible.
My point is that as soon as Proxies will be standardized, it will become
impossible to add fundamental traps without either breaking existing code or
becoming inconsistent.
In my opinion, the extensibility problem is due to the fact that all traps
are trapped by default in proxies regardless if the user wants it or not.
Please allow me an analogy with DOM events. I see proxy traps as events on
ECMAScript objects. When in the code a delete happens, a /delete/ event
happens, it is trapped and the delete handler function is called like a event
handler for a DOMEventListener.
Capturing all
Re: 2nd day meeting comments on the latest i18n API proposal
I for one am very much against setting inferValues to true by default.
That's just obfuscating i18n bugs, and I think we should design our APIs
so that it's easy to get it right. Shooting yourself in the foot should
be hard, if at all possible.
Axel
On 21.01.11 09:39, Nebojša Ćirić wrote:
If we were to go with loc.options, I would define it as having only
items that were explicitly listed when object was constructed. So:
var loc = new LocaleInfo({'calendar':'hijri', 'lang': 'en-US',
'inferValues': true});
loc.options would contain:
loc.options.calendar - hijri
loc.options.lang - en-US
loc.options.inferValues - true
loc object would have:
loc.currency
loc.lang
loc.inferValues
loc.calendar (maybe)
loc.region
...
One could implement isInferred(x) method like this:
function isInferred(x) {
if (x in loc.options x in loc loc.options.x === x)
return false;
else
return true;
There would be some duplication of data with this approach, but it would
give us easy way to check what were the options we passed in when
constructed the object, and to detect if the value was inferred or not.
Btw. I think we agreed to have inferreValues set to true by default.
20. јануар 2011. 22.15, Peter Constable peter...@microsoft.com
mailto:peter...@microsoft.com је написао/ла:
We had talked about having an option on the LocaleInfo constructor
to control whether values not explicitly set could be inferred. E.g.
var loc = new LocaleInfo({lang:”en-US”, inferValues:true});
var curr = loc.currency; // is USD
With the approach of having .derive() methods, then the constructed
clone is exactly the same. So, for instance,
var loc2 = loc.derive({calendar:hijri});
if (loc2.isInferred(currency)) // is true
Considering this other approach, when I get opt2…
var opt2 = loc.options;
what all does opt2 include? Does it include only options that were
explicitly passed in when loc was constructed, or does it include
specific values for all LocaleInfo properties that could be set as
options and could be inferred? If the latter, does it reflect that
most of them were inferred?
Peter
*From:*Nebojša Ćirić [mailto:c...@google.com mailto:c...@google.com]
*Sent:* Wednesday, January 19, 2011 5:02 PM
*To:* es-discuss@mozilla.org mailto:es-discuss@mozilla.org
*Subject:* 2nd day meeting comments on the latest i18n API proposal
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);
This approach yields the same result with more code, but it's a more
in sync with how people expect JavaScript API to work.
In this case LocaleInfo needs to have options property that holds
original inputs. This approach could also help with inferred values
- one can compare options with actual property and see if they are
the same.
var loc = LocaleInfo({currency: 'USD'});
if (loc.options.currency == loc.currency) ...
--
Nebojša Ćirić
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: On ES Harmony proxies extensibility
We have previously discussed adding standard handlers to the specification, i.e. an NoopHandler and a ForwardingHandler. Yes, and Tom and Mark have been working on this and making good progress. They have a forwarding handler mostly worked out, which we discussed yesterday at the face-to-face meeting. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 2nd day meeting comments on the latest i18n API proposal
I would actually rather not have it be a construction argument, because it
is easier for people to make mistakes that way.
When I look this over, there are relatively few fields that need this. So
what about having API like:
// get an explicitly-set region, or null if there was no region parameter in
the constructor.
region1 = myLocaleInfo.region;
// gets myLocaleInfo.region if not null
// otherwise infers the region from other information in the LocaleInfo.
aRegion = myLocaleInfo.inferRegion();
The ones where this would be done would be:
inferBaseLanguage()
inferScript()
inferRegion()
inferCurrency()
// later: inferTimeZone()
Mark
*— Il meglio è l’inimico del bene —*
On Fri, Jan 21, 2011 at 11:19, Axel Hecht a...@mozilla.com wrote:
I for one am very much against setting inferValues to true by default.
That's just obfuscating i18n bugs, and I think we should design our APIs so
that it's easy to get it right. Shooting yourself in the foot should be
hard, if at all possible.
Axel
On 21.01.11 09:39, Nebojša Ćirić wrote:
If we were to go with loc.options, I would define it as having only
items that were explicitly listed when object was constructed. So:
var loc = new LocaleInfo({'calendar':'hijri', 'lang': 'en-US',
'inferValues': true});
loc.options would contain:
loc.options.calendar - hijri
loc.options.lang - en-US
loc.options.inferValues - true
loc object would have:
loc.currency
loc.lang
loc.inferValues
loc.calendar (maybe)
loc.region
...
One could implement isInferred(x) method like this:
function isInferred(x) {
if (x in loc.options x in loc loc.options.x === x)
return false;
else
return true;
There would be some duplication of data with this approach, but it would
give us easy way to check what were the options we passed in when
constructed the object, and to detect if the value was inferred or not.
Btw. I think we agreed to have inferreValues set to true by default.
20. јануар 2011. 22.15, Peter Constable peter...@microsoft.com
mailto:peter...@microsoft.com је написао/ла:
We had talked about having an option on the LocaleInfo constructor
to control whether values not explicitly set could be inferred. E.g.
var loc = new LocaleInfo({lang:”en-US”, inferValues:true});
var curr = loc.currency; // is USD
With the approach of having .derive() methods, then the constructed
clone is exactly the same. So, for instance,
var loc2 = loc.derive({calendar:hijri});
if (loc2.isInferred(currency)) // is true
Considering this other approach, when I get opt2…
var opt2 = loc.options;
what all does opt2 include? Does it include only options that were
explicitly passed in when loc was constructed, or does it include
specific values for all LocaleInfo properties that could be set as
options and could be inferred? If the latter, does it reflect that
most of them were inferred?
Peter
*From:*Nebojša Ćirić [mailto:c...@google.com mailto:c...@google.com]
*Sent:* Wednesday, January 19, 2011 5:02 PM
*To:* es-discuss@mozilla.org mailto:es-discuss@mozilla.org
*Subject:* 2nd day meeting comments on the latest i18n API proposal
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);
This approach yields the same result with more code, but it's a more
in sync with how people expect JavaScript API to work.
In this case LocaleInfo needs to have options property that holds
original inputs. This approach could also help with inferred values
- one can compare options with actual property and see if they are
the same.
var loc = LocaleInfo({currency: 'USD'});
if (loc.options.currency == loc.currency) ...
--
Nebojša Ćirić
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: 2nd day meeting comments on the latest i18n API proposal
IMO that’s going overboard in the other direction ☺ It’d be nice to find some
middle ground.
Sometimes inferring can be very bad. Sometimes it can be very good. The
problem isn’t that one is “right” or “wrong” for all apps, but rather that it
might be simple for developers to accidentally make the wrong choice, or not
realize they need to make a choice. If I need to infer, it should be easy to
get a fully-inferred LocaleInfo. If I don’t need to infer, then it should be
easy to avoid inferring for LocaleInfo.
-Shawn
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Mark Davis ?
Sent: Friday, January 21, 2011 12:44 PM
To: Axel Hecht
Cc: Derek Murman; es-discuss@mozilla.org
Subject: Re: 2nd day meeting comments on the latest i18n API proposal
I would actually rather not have it be a construction argument, because it is
easier for people to make mistakes that way.
When I look this over, there are relatively few fields that need this. So what
about having API like:
// get an explicitly-set region, or null if there was no region parameter in
the constructor.
region1 = myLocaleInfo.region;
// gets myLocaleInfo.region if not null
// otherwise infers the region from other information in the LocaleInfo.
aRegion = myLocaleInfo.inferRegion();
The ones where this would be done would be:
inferBaseLanguage()
inferScript()
inferRegion()
inferCurrency()
// later: inferTimeZone()
Mark
— Il meglio è l’inimico del bene —
On Fri, Jan 21, 2011 at 11:19, Axel Hecht
a...@mozilla.commailto:a...@mozilla.com wrote:
I for one am very much against setting inferValues to true by default. That's
just obfuscating i18n bugs, and I think we should design our APIs so that it's
easy to get it right. Shooting yourself in the foot should be hard, if at all
possible.
Axel
On 21.01.11 09:39, Nebojša Ćirić wrote:
If we were to go with loc.options, I would define it as having only
items that were explicitly listed when object was constructed. So:
var loc = new LocaleInfo({'calendar':'hijri', 'lang': 'en-US',
'inferValues': true});
loc.options would contain:
loc.options.calendar - hijri
loc.options.lang - en-US
loc.options.inferValues - true
loc object would have:
loc.currency
loc.lang
loc.inferValues
loc.calendar (maybe)
loc.region
...
One could implement isInferred(x) method like this:
function isInferred(x) {
if (x in loc.options x in loc loc.options.x === x)
return false;
else
return true;
There would be some duplication of data with this approach, but it would
give us easy way to check what were the options we passed in when
constructed the object, and to detect if the value was inferred or not.
Btw. I think we agreed to have inferreValues set to true by default.
20. јануар 2011. 22.15, Peter Constable
peter...@microsoft.commailto:peter...@microsoft.com
mailto:peter...@microsoft.commailto:peter...@microsoft.com је написао/ла:
We had talked about having an option on the LocaleInfo constructor
to control whether values not explicitly set could be inferred. E.g.
var loc = new LocaleInfo({lang:”en-US”, inferValues:true});
var curr = loc.currency; // is USD
With the approach of having .derive() methods, then the constructed
clone is exactly the same. So, for instance,
var loc2 = loc.derive({calendar:hijri});
if (loc2.isInferred(currency)) // is true
Considering this other approach, when I get opt2…
var opt2 = loc.options;
what all does opt2 include? Does it include only options that were
explicitly passed in when loc was constructed, or does it include
specific values for all LocaleInfo properties that could be set as
options and could be inferred? If the latter, does it reflect that
most of them were inferred?
Peter
*From:*Nebojša Ćirić [mailto:c...@google.commailto:c...@google.com
mailto:c...@google.commailto:c...@google.com]
*Sent:* Wednesday, January 19, 2011 5:02 PM
*To:* es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
mailto:es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
*Subject:* 2nd day meeting comments on the latest i18n API proposal
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);
This approach yields the same result with more code, but it's a more
in sync with how people expect JavaScript API to work.
In this case LocaleInfo needs to have options property that holds
original inputs. This approach could also help with inferred values
- one can compare options with actual property and see if they are
the same.
var loc = LocaleInfo({currency: 'USD'});
if (loc.options.currency == loc.currency) ...
--
Nebojša Ćirić
--
Nebojša
Re: On ES Harmony proxies extensibility
Should we have a no-op or sink standard handler too? I think so, yes. Especially since you can use that to build one up that implements just the other traps you want to implement, and let the others fail soft. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 2nd day meeting comments on the latest i18n API proposal
The problem I see is that if I hand you a LocaleInfo, and there is only one
API to get the region, then it (in your words) **is easy** to accidentally
make the wrong choice, or not realize they need to make a choice.
- x.region may be an explicit value or may be computed: I have to call
some other API to find out.
If we have a separate API, then I, the developer, have it clearly in front
of me what choice I am to to make, and it **is harder** to accidentally make
the wrong choice, c.
- x.region is always an explicit value
- x.inferRegion() is computed if there is no explicit value.
Mark
*— Il meglio è l’inimico del bene —*
On Fri, Jan 21, 2011 at 14:04, Shawn Steele shawn.ste...@microsoft.comwrote:
IMO that’s going overboard in the other direction J It’d be nice to find
some middle ground.
Sometimes inferring can be very bad. Sometimes it can be very good. The
problem isn’t that one is “right” or “wrong” for all apps, but rather that
it might be simple for developers to accidentally make the wrong choice, or
not realize they need to make a choice. If I need to infer, it should be
easy to get a fully-inferred LocaleInfo. If I don’t need to infer, then it
should be easy to avoid inferring for LocaleInfo.
-Shawn
*From:* es-discuss-boun...@mozilla.org [mailto:
es-discuss-boun...@mozilla.org] *On Behalf Of *Mark Davis ?
*Sent:* Friday, January 21, 2011 12:44 PM
*To:* Axel Hecht
*Cc:* Derek Murman; es-discuss@mozilla.org
*Subject:* Re: 2nd day meeting comments on the latest i18n API proposal
I would actually rather not have it be a construction argument, because it
is easier for people to make mistakes that way.
When I look this over, there are relatively few fields that need this. So
what about having API like:
// get an explicitly-set region, or null if there was no region parameter
in the constructor.
region1 = myLocaleInfo.region;
// gets myLocaleInfo.region if not null
// otherwise infers the region from other information in the LocaleInfo.
aRegion = myLocaleInfo.inferRegion();
The ones where this would be done would be:
inferBaseLanguage()
inferScript()
inferRegion()
inferCurrency()
// later: inferTimeZone()
Mark
*— Il meglio è l’inimico del bene —*
On Fri, Jan 21, 2011 at 11:19, Axel Hecht a...@mozilla.com wrote:
I for one am very much against setting inferValues to true by default.
That's just obfuscating i18n bugs, and I think we should design our APIs so
that it's easy to get it right. Shooting yourself in the foot should be
hard, if at all possible.
Axel
On 21.01.11 09:39, Nebojša Ćirić wrote:
If we were to go with loc.options, I would define it as having only
items that were explicitly listed when object was constructed. So:
var loc = new LocaleInfo({'calendar':'hijri', 'lang': 'en-US',
'inferValues': true});
loc.options would contain:
loc.options.calendar - hijri
loc.options.lang - en-US
loc.options.inferValues - true
loc object would have:
loc.currency
loc.lang
loc.inferValues
loc.calendar (maybe)
loc.region
...
One could implement isInferred(x) method like this:
function isInferred(x) {
if (x in loc.options x in loc loc.options.x === x)
return false;
else
return true;
There would be some duplication of data with this approach, but it would
give us easy way to check what were the options we passed in when
constructed the object, and to detect if the value was inferred or not.
Btw. I think we agreed to have inferreValues set to true by default.
20. јануар 2011. 22.15, Peter Constable peter...@microsoft.com
mailto:peter...@microsoft.com је написао/ла:
We had talked about having an option on the LocaleInfo constructor
to control whether values not explicitly set could be inferred. E.g.
var loc = new LocaleInfo({lang:”en-US”, inferValues:true});
var curr = loc.currency; // is USD
With the approach of having .derive() methods, then the constructed
clone is exactly the same. So, for instance,
var loc2 = loc.derive({calendar:hijri});
if (loc2.isInferred(currency)) // is true
Considering this other approach, when I get opt2…
var opt2 = loc.options;
what all does opt2 include? Does it include only options that were
explicitly passed in when loc was constructed, or does it include
specific values for all LocaleInfo properties that could be set as
options and could be inferred? If the latter, does it reflect that
most of them were inferred?
Peter
*From:*Nebojša Ćirić [mailto:c...@google.com mailto:c...@google.com]
*Sent:* Wednesday, January 19, 2011 5:02 PM
*To:* es-discuss@mozilla.org mailto:es-discuss@mozilla.org
*Subject:* 2nd day meeting comments on the latest i18n API proposal
Eric proposed to remove the derive method from all API objects and
do something like this:
var loc = new LocaleInfo({}); // {...} are the
RE: 2nd day meeting comments on the latest i18n API proposal
I think a reasonable approach is to tag the localeinfo itself as “please infer”
or “do not infer”. Then I don’t have to use special code in a helper API for a
caller that wants one behavior or the other. And it’s reasonably trivial for
me to collect the information. Presumably I could even do a .Derive() (or
whatever it turns out to be) and get an inferred object from an non-inferred
object (or visa versa).
While I’d prefer “please infer” by default, I recognize that approach doesn’t
avoid user error as much as the “do not infer” by default approach. I think
that requiring “please infer” in the input options would help avoid
accidentally not making a choice, yet still making it fairly easy to use.
-Shawn
From: mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] On
Behalf Of Mark Davis ?
Sent: Friday, January 21, 2011 4:01 PM
To: Shawn Steele
Cc: Axel Hecht; Derek Murman; es-discuss@mozilla.org
Subject: Re: 2nd day meeting comments on the latest i18n API proposal
The problem I see is that if I hand you a LocaleInfo, and there is only one API
to get the region, then it (in your words) *is easy* to accidentally make the
wrong choice, or not realize they need to make a choice.
* x.region may be an explicit value or may be computed: I have to call some
other API to find out.
If we have a separate API, then I, the developer, have it clearly in front of
me what choice I am to to make, and it *is harder* to accidentally make the
wrong choice, c.
* x.region is always an explicit value
* x.inferRegion() is computed if there is no explicit value.
Mark
— Il meglio è l’inimico del bene —
On Fri, Jan 21, 2011 at 14:04, Shawn Steele
shawn.ste...@microsoft.commailto:shawn.ste...@microsoft.com wrote:
IMO that’s going overboard in the other direction ☺ It’d be nice to find some
middle ground.
Sometimes inferring can be very bad. Sometimes it can be very good. The
problem isn’t that one is “right” or “wrong” for all apps, but rather that it
might be simple for developers to accidentally make the wrong choice, or not
realize they need to make a choice. If I need to infer, it should be easy to
get a fully-inferred LocaleInfo. If I don’t need to infer, then it should be
easy to avoid inferring for LocaleInfo.
-Shawn
From: es-discuss-boun...@mozilla.orgmailto:es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.orgmailto:es-discuss-boun...@mozilla.org]
On Behalf Of Mark Davis ?
Sent: Friday, January 21, 2011 12:44 PM
To: Axel Hecht
Cc: Derek Murman; es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: 2nd day meeting comments on the latest i18n API proposal
I would actually rather not have it be a construction argument, because it is
easier for people to make mistakes that way.
When I look this over, there are relatively few fields that need this. So what
about having API like:
// get an explicitly-set region, or null if there was no region parameter in
the constructor.
region1 = myLocaleInfo.region;
// gets myLocaleInfo.region if not null
// otherwise infers the region from other information in the LocaleInfo.
aRegion = myLocaleInfo.inferRegion();
The ones where this would be done would be:
inferBaseLanguage()
inferScript()
inferRegion()
inferCurrency()
// later: inferTimeZone()
Mark
— Il meglio è l’inimico del bene —
On Fri, Jan 21, 2011 at 11:19, Axel Hecht
a...@mozilla.commailto:a...@mozilla.com wrote:
I for one am very much against setting inferValues to true by default. That's
just obfuscating i18n bugs, and I think we should design our APIs so that it's
easy to get it right. Shooting yourself in the foot should be hard, if at all
possible.
Axel
On 21.01.11 09:39, Nebojša Ćirić wrote:
If we were to go with loc.options, I would define it as having only
items that were explicitly listed when object was constructed. So:
var loc = new LocaleInfo({'calendar':'hijri', 'lang': 'en-US',
'inferValues': true});
loc.options would contain:
loc.options.calendar - hijri
loc.options.lang - en-US
loc.options.inferValues - true
loc object would have:
loc.currency
loc.lang
loc.inferValues
loc.calendar (maybe)
loc.region
...
One could implement isInferred(x) method like this:
function isInferred(x) {
if (x in loc.options x in loc loc.options.x === x)
return false;
else
return true;
There would be some duplication of data with this approach, but it would
give us easy way to check what were the options we passed in when
constructed the object, and to detect if the value was inferred or not.
Btw. I think we agreed to have inferreValues set to true by default.
20. јануар 2011. 22.15, Peter Constable
peter...@microsoft.commailto:peter...@microsoft.com
mailto:peter...@microsoft.commailto:peter...@microsoft.com је написао/ла:
We had talked about having an option on the LocaleInfo constructor
to control whether values not explicitly set could be inferred. E.g.
var loc = new LocaleInfo({lang:”en-US”,
Re: On ES Harmony proxies extensibility
Not sure; I'll think about it. Though abstracting
Proxy.Handler(Object.create(null, {})) might in fact be a worthwhile
convenience.
Dave
Mark S. Miller erig...@google.com wrote:
On Fri, Jan 21, 2011 at 2:45 PM, David Herman dher...@mozilla.com
wrote:
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up
that
implements just the other traps you want to implement, and let the
others
fail soft.
How would it be different from
new Proxy.Handler(Object.create(null, {}))
?
Or, depending on how soft you want to fail
new Proxy.Handler(null)
?
If there is a useful difference, I have no objection.
Dave
--
Cheers,
--MarkM
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
