Globalization API Feedback - moar!
anton.yacenko at gmail.com
Wed Nov 30 22:25:53 PST 2011
Let me propose, guys:
If time for specification draft + vendors basic implementation less than time to implement fully module based API (get rid of globals at all), then another global name is a solution.
As this topic strategic targeted (IMO) I think it makes sense to draft both options — as a developer I don't care how to call needed method (using module or directly) in any case all tools will use wrappers, so basically:
local = Globalization;
local = Object.System.loaded['@globalization'];
are the same as much as methods API consistent.
In case I've missed point — sorry.
On Dec 1, 2011, at 7:55 AM, Brendan Eich wrote:
> On Nov 30, 2011, at 9:52 PM, Luke Hoban wrote:
>>> Speaking on behalf of real world web developers, the opposition to "Globalization" is that it's unnecessarily long. This is a long standing problem with APIs that are designed by people that don't have to use them everyday.
>> Agreed - a shorter name would be better - but the alternative being discussed here is not a shorter name - it's this tradeoff:
>> "Globalization" vs. "Object.System.loaded['@globalization']"
> As I just suggested in reply to Rick, I think micro-optimizing here for brevity is not the main thing. Most developers will want the Date.prototype, etc. extensions -- easy to use and better-localizable methods.
> All the full-metal OOP APIs for amortizing collator construction costs, etc., will be used less frequently, even if by some big web app properties.
>> That is, the alternative here is 3 times as long as the already 'unnecessarily long' option. As Brendan noted, we still need to do the API design on the system module loader to try to streamline this - but the design space currently being explored won't lead to this being shorter than "Globalization", so the length argument by itself would seem to favor a single global name.
>> There was an earlier thread discussing alternatives to "Globalization", several of which are shorter and may be appropriate choices instead.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss