On Jul 18, 2008, at 9:02 AM, Allen Wirfs-Brock wrote: > We ultimately concluded that the best way to think about what we > are currently provide is that it is a set of primitive mechanisms > that could be used to build higher level reflection facilities. If > we had a strong use case we could reintroduce getOwnProperties as > such a primitive, but so far it seem non-essential. Incidentally, > when we removed getOwnProperties we had to add getOwnPropertyName > because otherwise you won't necessarily know what properties to ask > for using getOwnProperty
This trade-off comes up often with widely-targeted languages. JS is a case in point, but since it was over-minimized at the start, prematurely standarized, and then not evolved in the standard form for too long, the libraries have had to make up for the over- minimization, with inevitable gratuitous differences (minor, usually, in the case of functions like Object.extend). Providing minimal, low-level facilities is not necessarily the best approach. If the audience demonstrably needs and already uses sugar, or a clichéd composite op, the language should give the people what they want. If the low-level primitive (call/cc) is too hard to use for most users, at least Lars and I have argued that simpler, easier- to-use, higher-level functionality (generators, based on Python -- just one example) wins. If Object.extend is the common case, but as Igor shows it can be built on (new name alert, and "own" only) Object.getPropertyDescriptors and defineProperties, it may be fine to provide only Object.extend and defer Object.getPropertyDescriptors. My own view is that at this point, given the proposed API, it's better to provide both. The low-level primitive for the uncommon cases not yet seen or thought of, and the higher-level API for the many libraries that roll their own equivalents. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
