I guess I don't see why you would normally want to make your methods enumerable (other than that up until the general availability of ES5 implementations there is no standard way for you to make them non-enumerable). The primary (and presumably original) purpose of the enumerable attribute is to support the for-in statement. This statement is pretty clearly intended as a way to iterate over the "data" content of an object. That's why the "method" properties of built-in objects are non-enumerable as are most of their control state data properties such as Array length or Object.prototype.constructor. In general, you just don't want these things to show up in for-in or similar sorts of iterations.
If you are concerned that making "methods" non-enumerable would mean that they would not be discoverable, that shouldn't be an issue. In ES3 for-in enumeration is really the only standard way to enquire about what properties existed for an object and since there was no way to define non-enumerable properties your were assured that for-in would show you all the non-builtin properties of an object. Starting with ES5 there is a better way. Object.getOwnPropertyNames(obj) will give you a list of all property names, regardless of whether or not they are enumerable.
As ES5 provides a mechanism (Object.defineProperty) that gives complete control over all property attribute settings you can define the attributes of your properties to have whatever settings you want. However this flexibility carries the cost of added verbosity and complexity. The intent of the enhanced object initialiser proposals is to provide a simpler and more concise syntax for the most common property definition use cases. One of these use cases is defining properties that are intended to be exclusively used as methods.
I'm quite certain that non-enumerable is what is most commonly desired for such method properties. Readonly-ness is certainly more debatable. I'm pretty sure that most programmer, most of the time, when they define a "method" are not doing so with the expectation that it will be dynamically replaced. However, there is also power that comes for the ability to arbitrarily "patch" other people's objects and I know that some members of the JavaScript community are worried about web applications becoming too brittle if various mechanisms to "freeze" objects are overused. From that perspective giving "method" properties the attributes {enumerable: false, writable: false, configurable: true} may be a better compromise between programmer intent and excessive brittleness than {enumerable: false, writable: false, configurable: false} that is currently in the strawman proposal.
>-----Original Message-----
>From:
es-discuss-bounces@... [mailto:es-discuss-
>
bounces@...] On Behalf Of Daniel Friesen
>Sent: Tuesday, August 11, 2009 3:12 PM
>To:
es-discuss@...
>Subject: Re: Object Initialiser Extensions Strawman
>
>This is just a comment from someone outside the group, but...
>Taking a look at the method properties and const modifiers I notice one
>thing that seams superfluous and another that seams missing.
>
>If I read the proposals there correctly, then the proposed:
>var obj = {
>method foo() {/* ... */}
>};
>Is syntactically the same as:
>var obj = {
>const: function foo() {/* ... */}
>};
>
>The thing that I see missing is functions that are just non-enumerable.
>
>Personally during programming, most of the time I wouldn't want to
>create methods of an object that are non-enumerable (though I do see
>reasons other might) but I do see reason to want to create methods that
>are still writable and configurable, but are non-enumerable.
>
>Taking a look at some of the engines, it seams that methods on most of
>the standard prototypes are non-enumerable, however they are still
>writable and configurable.
>
>I can see reasons for someone to want to create prototypes for their
>classes with non-enumerable methods.
>
>Also from my perspective the word "method" doesn't exactly signify
>non-writable, non-configurable to me, I can understand non-enumerable
>since it's being declared that's it's not a normal property, but it
>doesn't signify permanency any more than function does imho.
>
>
>Rather than using the keyword method, I'd propose at least reusing
>const, and using method to refer to non-enumerable, but still writable
>and deletable methods on an object.
>var obj = {
>method foo() {/* this function property is deletable and configurable,
>but not enumerable },
>const bar() {/* this function property is non-deletable,
>non-configurable, and non-enumerable (going by what was written in the
>const proposal) */ }
>};
>The idea of `const fn() {}` comes from the `const fn() { /* ... */ }`
>pseudonym I've seen used here on this list and in the strawmans to refer
>to non-modifiable functions.
>
>A little stretch but alternatively `const method fn() { }` could be used
>instead, but I don't see to much reason for that unless the decision to
>tie certain keywords to certain attribute states and combine them
>together in this way (like how other languages like Java may use
>something like public static final ...).
>
>~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
>
>Allen Wirfs-Brock wrote:
>>
>> At the last TC39 meeting we talked briefly about a few possible ways
>> to extend object literals in Harmony in order to improve their utility
>> as an abstraction mechanism.
>>
>> I've written up a strawman proposal that covers a few possible such
>> extensions. It can be found here at
>>
>
http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_exten>sions
>>
>> Allen
>>
>> ----------------------------------------------------------------------
>--
>>
>> _______________________________________________
>> es-discuss mailing list
>>
es-discuss-4eJtQOnFJqFAfugRpC6u6w@...
>>
https://mail.mozilla.org/listinfo/es-discuss>>
>
>--
>~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
>_______________________________________________
>es-discuss mailing list
>
es-discuss@...
>
https://mail.mozilla.org/listinfo/es-discuss
Some parts of this message have been removed.
Learn more about Nabble's security policy.
