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 */
Discussions:
getProperty change
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.
Actions:
rename Object.getPropertyDescriptor to Object.getOwnPropertyDescriptor
delete Object.getOwnProperty
Object.const/Objct.isConst renaming
No controversy, everybody was happy with these changes
Actions: none
Added Object.nonExtensible(o)
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.
Actions: none
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"
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
