Object.methods

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Aug 23 16:07:28 PDT 2011


On Aug 9, 2011, at 2:05 PM, Dmitry A. Soshnikov wrote:

> On 24.08.2011 0:39, Allen Wirfs-Brock wrote:
>> 
>> 
>> I'm don't really see the that they are needed enough to build these in when they can be synthesized pretty easily.  What is the justification for these and not others such as getAccessorProperties, getDataProperties, getNonWritableProperties, etc.  
>> 
> 
> Maybe, why not? `Object.methods` is just standard in some languages (e.g. Ruby, `foo.instance_methods`). Yes, all of yours listed above could be either built-in or self-implemented, don't know how often they are needed IRL. This topic follows the recent near topic with doc-comments of functions. The same, playing with a new language in console it's the best just to type e.g. `foo.methods` (like in Ruby) and to see directly the list of methods to which the object responds. Besides, perhaps they can be used in other meta-level programming, but the initial idea seems studying the language in the console and playing with objects (not sure though whether it's a sound reason to be accepted for standardization).
> 
> Dmitry.
> 

One difference between Ruby and JavaScript is that Ruby has a formal concept of method and JavaScript does not.  Whether a JS data property whose value is a function is considered to be a method or function valued instance variable is highly situational.  Similarly, I can also imagine an interpretation that only inherited function valued data properties are considered to be methods or that methods need to be non-writable and non-enumerable.  Adding super bindings also complicates things.  Perhaps, only properties with function values that have super bindings to the object or one of its prototypes should be considered a method.  Which of these definitions should be use for a built-in Object.methods.

I'm all for rich interactive environments for working with JavaScript and such environments do need to access or infer metadata about JavaScript code.  However, I don't necessarily think the a REPL model is the best exemplar for such an environment.  Also there can be real problems with exposing too much program metadata directly to the application layer. I've had lots of experience with Smalltalk environments where this was the case and it leads to a muddling of the metalayers and the application layers of a system because many developers don't understand the concepts of stratification well enough to know which methods are not really appropriate for use in application logic. 




More information about the es-discuss mailing list