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; and local = Object.System.loaded['@globalization']; are the same as much as methods API consistent. In case I've missed point — sorry. Anton. 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. > > /be > > >> >> 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. >> >> Luke >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
