Re: Comments on internationalization API
You make some good points (and many that I agree with), but the main issue
is that we are having to produce a model that all the browser vendors can
sign up to. That necessitates some compromises, including some areas where
we can't have a concrete specification because the implementors want the
freedom to implement the functionality in different ways.
If you want to engage more, there is a F2F next week. Cira can get you
details.
Mark
*— Il meglio è l’inimico del bene —*
On Thu, Jul 21, 2011 at 17:14, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
Hi Mark,
Thanks for your comments! Replies to some of them below. I also noticed
some additional issues:
19. DateTimeFormat.prototype.getMonths needs a second parameter {boolean}
standalone, default value false.
20. There needs to be a way to determine the actual language, region, and
options of a Collator, NumberFormat, or DateTimeFormat. E.g., if I request
ar-MA-u-ca-islamic, did I get exactly what I requested, or
ar-MA-u-ca-islamicc, ar-MA-u-ca-gregory, ar-u-ca-gregory, or yet something
else?
Best regards,
Norbert
On Jul 20, 2011, at 9:46 , Mark Davis ☕ wrote:
I have comments on some of these.
Mark
— Il meglio è l’inimico del bene —
On Tue, Jul 19, 2011 at 01:29, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
Hi all,
I'm sorry for not having been able to contribute to the
internationalization API earlier. I finally have reviewed the straw man [1],
and am pleased to see that it contains a good subset of internationalization
functionality to start with. Number and date formatting and collation are
issues that most applications have to deal with. Collation especially, but
also date formatting with support for multiple time zones and calendars are
hard to implement as downloadable libraries.
I have some comments on the details though:
1. In the background section, it might be useful to add that with
Node.js server-side JavaScript is seeing a rebound, and applications don't
really want to have to call out to a non-JavaScript server in order to
handle basic internationalization.
2. In the goals section, I'd qualify the reuse of objects goal as a
reuse of implementation data structures, or even better replace it with
measurable performance goals. Reuse of objects that are visible to
applications has security and privacy implications, especially when loading
third party code (apps or ads) onto pages [2]. I'd recommend letting
applications freely construct Collator, NumberFormat, and DateTimeFormat
objects, but have these objects share implementation objects (such as ICU
objects) as much as possible. If the API does return shared objects, the
security issues need to be dealt with, e.g., by specifying that the shared
objects are immutable.
I think it is reasonable to rephrase this as implementation data
structures.
3. I'm very uncomfortable with the LocaleInfo class. It seems to pretend
being the central source of all locale-related information, but can't live
up to that claim because its design is limited to number and date formatting
and collation. Developers will need to create other functionality such as
text segmentation, spelling checking, message lookup, shoe size conversion,
etc. LocaleInfo appears to perform some magic to derive regions, currencies,
and possibly time zones, but doesn't specify it, and makes none of it
available to other internationalization classes. It also does duty as a
namespace, which looks odd in an EcmaScript standard that otherwise doesn't
know namespaces.
I don't think it is ideal; I share some of your qualms about it. However,
it is what we were able to compromise on. Because the LocaleInfo class does
do the resolution, and that information is available after creation, the
information is available for other services. And people could (being ES)
hang services off of their own LocaleInfo class.
So is this the current recommendation?: A library that provides word break
and line break functionality should be based on a class MyLocaleInfo, which
provides WordBreak and LineBreak classes whose constructors clients should
not call, and wordBreak and lineBreak functions that return objects of these
classes. An application that uses multiple such libraries (providing
different sets of internationalized functionality) has to create objects of
all their LocaleInfo classes so that it can request objects of the classes
that it actually needs.
What value do these LocaleInfo classes add, compared to having constructors
of the actually needed classes that can be called directly?
Also, the LocaleInfo API, as currently documented, doesn't provide any
information that a third party internationalization library could use. Some
comments sound like there should be a property options, but this property
and the derivation of its values aren't actually documented.
Other internationalization libraries have a core
JavaScript terminology: non-function-valued property
I’m still wondering if there is an established term for a non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are: - instance variable - member variable - field OO literature sometimes uses the term “attribute” but that is already taken by ES-262. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript terminology: non-function-valued property
On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote: I’m still wondering if there is an established term for a non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are: Why do you need this term? In what practical sentence would you use it? /be - instance variable - member variable - field OO literature sometimes uses the term “attribute” but that is already taken by ES-262. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ 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: JavaScript terminology: non-function-valued property
To contrast non-method properties with methods: - To say that instances usually only have non-method properties. - To say that primitives can have non-method properties, but don’t have their own methods (they borrow them from their wrapper types). Maybe “non-method property” is good enough for that purpose. On Jul 23, 2011, at 0:00 , Brendan Eich wrote: On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote: I’m still wondering if there is an established term for a non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are: Why do you need this term? In what practical sentence would you use it? /be - instance variable - member variable - field OO literature sometimes uses the term “attribute” but that is already taken by ES-262. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript terminology: non-function-valued property
Which primitives have own properties? I thought even str.length conceptually came from the prototype. Mike On Jul 22, 2011 6:13 PM, Axel Rauschmayer a...@rauschma.de wrote: To contrast non-method properties with methods: - To say that instances usually only have non-method properties. - To say that primitives can have non-method properties, but don’t have their own methods (they borrow them from their wrapper types). Maybe “non-method property” is good enough for that purpose. On Jul 23, 2011, at 0:00 , Brendan Eich wrote: On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote: I’m still wondering if there is an established term for a non-function-valued property in the JavaScript community (where method is a term for a function-valued property). Possibilities that I see are: Why do you need this term? In what practical sentence would you use it? /be - instance variable - member variable - field OO literature sometimes uses the term “attribute” but that is already taken by ES-262. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ 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: JavaScript terminology: non-function-valued property
Possible. I assumed, because String.prototype.length does not seem to be
generic (in the sense that, say, String.prototype.trim() is).
Object.getOwnPropertyDescriptor(String.prototype, length)
{ value: 0,
writable: false,
enumerable: false,
configurable: false }
In contrast, trim() is clearly borrowed from the wrapper’s prototype:
.trim === String.prototype.trim
true
ES-262, Sect. 8.4 only says: “The String type is the set of all finite ordered
sequences of zero or more 16-bit unsigned integer values” (etc.). It does not
mention how indexed access or length is handled.
On Jul 23, 2011, at 0:16 , Mike Shaver wrote:
Which primitives have own properties? I thought even str.length
conceptually came from the prototype.
Mike
On Jul 22, 2011 6:13 PM, Axel Rauschmayer a...@rauschma.de wrote:
To contrast non-method properties with methods:
- To say that instances usually only have non-method properties.
- To say that primitives can have non-method properties, but don’t have
their own methods (they borrow them from their wrapper types).
Maybe “non-method property” is good enough for that purpose.
On Jul 23, 2011, at 0:00 , Brendan Eich wrote:
On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote:
I’m still wondering if there is an established term for a
non-function-valued property in the JavaScript community (where method is
a term for a function-valued property). Possibilities that I see are:
Why do you need this term? In what practical sentence would you use it?
/be
- instance variable
- member variable
- field
OO literature sometimes uses the term “attribute” but that is already
taken by ES-262.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript terminology: non-function-valued property
On 07/22/2011 03:16 PM, Mike Shaver wrote: Which primitives have own properties? I thought even str.length conceptually came from the prototype. Spec-wise, it comes from the boxed String object created when you attempt to look up a property on a primitive string. It's the same for str[0] and so on. (Serious implementations probably wouldn't actually box up the primitive in either case, of course, and would have fast-path logic.) Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript terminology: non-function-valued property
I'd like to speak on behalf of the JavaScript Community that you mentioned
above... Unequivocally, a property is a property and method is a property
whose value is a function.
Simply, property and method. This terminology is used widely in
publication and conversation.
Rick
On Fri, Jul 22, 2011 at 6:37 PM, Axel Rauschmayer a...@rauschma.de wrote:
Possible. I assumed, because String.prototype.length does not seem to be
generic (in the sense that, say, String.prototype.trim() is).
Object.getOwnPropertyDescriptor(String.prototype, length)
{ value: 0,
writable: false,
enumerable: false,
configurable: false }
In contrast, trim() is clearly borrowed from the wrapper’s prototype:
.trim === String.prototype.trim
true
ES-262, Sect. 8.4 only says: “The String type is the set of all finite
ordered sequences of zero or more 16-bit unsigned integer values” (etc.). It
does not mention how indexed access or length is handled.
On Jul 23, 2011, at 0:16 , Mike Shaver wrote:
Which primitives have own properties? I thought even str.length
conceptually came from the prototype.
Mike
On Jul 22, 2011 6:13 PM, Axel Rauschmayer a...@rauschma.de wrote:
To contrast non-method properties with methods:
- To say that instances usually only have non-method properties.
- To say that primitives can have non-method properties, but don’t have
their own methods (they borrow them from their wrapper types).
Maybe “non-method property” is good enough for that purpose.
On Jul 23, 2011, at 0:00 , Brendan Eich wrote:
On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote:
I’m still wondering if there is an established term for a
non-function-valued property in the JavaScript community (where method is a
term for a function-valued property). Possibilities that I see are:
Why do you need this term? In what practical sentence would you use it?
/be
- instance variable
- member variable
- field
OO literature sometimes uses the term “attribute” but that is already
taken by ES-262.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
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: JavaScript terminology: non-function-valued property
In strict-mode, this isn’t boxed in, say, String.prototype.* methods. But I don’t know how/whether that reflects the spec. On Jul 23, 2011, at 1:07 , Jeff Walden wrote: On 07/22/2011 03:16 PM, Mike Shaver wrote: Which primitives have own properties? I thought even str.length conceptually came from the prototype. Spec-wise, it comes from the boxed String object created when you attempt to look up a property on a primitive string. It's the same for str[0] and so on. (Serious implementations probably wouldn't actually box up the primitive in either case, of course, and would have fast-path logic.) Jeff -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript terminology: non-function-valued property
On 07/22/2011 04:13 PM, Axel Rauschmayer wrote: In strict-mode, this isn’t boxed in, say, String.prototype.* methods. But I don’t know how/whether that reflects the spec. This is not quite precisely true. See the second algorithm in 8.7 GetValue(V). If you implement exactly the steps in the spec, the boxing occurs whenever you look up a property on a primitive (step 1 of that algorithm) -- be that a data property whose value is a method, a data property whose value isn't a method, or an accessor property. It happens, however, that that boxed object itself is never directly exposed to code in the program being executed. So it's possible for an implementation to never actually box |this| in step 1, so long as it appears to behave as if it did. Note that if you have an accessor property looked up this way, the |this| seen, if |this| is boxed because the accessor is a function whose code is non-strict, is not *by the exact spec algorithm* the same as the object created in step 1 in the spec. But again, because the object in step 1 is never exposed, an implementation might box up only one object for both uses. (Or none, even, if it can get away with such an optimization -- say, because the accessor function never evaluates |this|.) Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
