Notes from 8/7 ES3.1 Teleconference
Allen.Wirfs-Brock at microsoft.com
Thu Aug 7 12:01:22 PDT 2008
Attending: Allen Wirfs-Brock, Douglas Crockford, Mark Miller, Sam Ruby
Topic: Review and Discuss name changes and additions to Object meta functions in 8/04 Draft.
Summary of 8/04 changes:
Rename Object.getProperty(o,p) to Object.getPropertyDescriptor(o,p)
renamed Object.const (o) to Object.freeze(o)
renamed Object.isConst(o) to Object.isFrozen(o)
added Object.nonExtensible(o) /*sets an object's internal [[Extensible]] property to false.*/
added Object.isExtensible(o) /* returns current state of an object's internal [[Extensible]] property */
Mark argues that for consistency it should be getOwnPropertyDescriptor
(after the meeting, Allen verified that there is an revision error in the 7/15 and 8/04 drafts that resulted in Object.getOwnProperty and Object.getProperty both existing with the same definition. The intent was to remove Object.getProperty so renaming Object.getOwnProperty to Object.getOwnPropertyDescriptor is the change that should have been made for the 8/04 draft).
Mark expressed concerns about the length of getOwnPropertyDescriptor. Allen reminded that getOwnProperty can be interpreted ambiguously as to whether it is retrieving a property value or a property descriptor (see previous thread on es4-discuss). Allen also argued that a long descriptive name is not necessarily bad for specialized a function that is intended for use by a limited audience.
rename Object.getPropertyDescriptor to Object.getOwnPropertyDescriptor
No controversy, everybody was happy with these changes
Nobody is particularly happy with this name. It's not clearly imperative or interrogative. Other possibilities discussed included; notExtensible, noExtensions, disallowExtensions, noNewProperties, close, limit, bound, preventExtensions. The first few have the same problem as nonExtensible. The words close, limit, and bound are either too general, have possible unintended semantic interpretations, or are too useful for other purposes. Favorites seem to be disallowExtensions and preventExtensions with preventExtensions being slightly preferred.
Action: rename Object.nonExtensible to Object.preventExtensions
Added Object. isExtensible()
No controversy, everybody was happy with the addition and name.
Topic: Should Object.keys be repositioned as Object.prototype.keys
Discussion: Allen argued that this isn't really a meta layer operation as it is intended for use in application layer code as an alternative to for..in for getting a list of enumerable property names. As a application layer method it belongs on Object.prototype rather than on the Object constructor. There was general agreement in principle, but it was pragmatically argued by Doug and Mark that it is too likely that a user defined object would define its own property named "keys" which would shadow Object.prototype.keys making it inaccessible for use on such objects.
Action: Leave it as Object.keys.
Topic: Since there is no long an potential ES4 conflict should the name of the "flexible" property attribute revert to the originally proposed name "dynamic"?
Discussion: Some possible alternative names:
dynamic - What it was going to be called until a conflict with ES4 proposal developed
sealed - corresponds to the name of the operation that turns it off for all properties of an object
fixed - another name similar to sealed
Mark no longer likes dynamic because of possible unintended interpretations such as dynamically scoped. Sealed and fixed diverge from the new attribute naming pattern which is to use a name that describes the more permissive state of boolean attributes or internal properties (eg, writable, enumerable, extensible). Flexible has the advantage that it probably doesn't carry with it any semantic preconceptions.
Action: Leave it as "flexible"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss