On 24.08.2011 3:07, Allen Wirfs-Brock wrote:
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.
(JFTR, moreover, Ruby has _only_ methods in this cases, that is,
accessors for private instance vars, but anyway it doesn't matter much)
I propose to use definition of a method as a "property which value is a
function". That's after all, is the same as from ES5 spec:
ECMA-262-5:
4.3.27
method
function that is the value of a property.
Whether a JS data property whose value is a function is considered to be a
method or function valued instance variable is highly situational.
For the simplicity and because instances themselves can store methods
and override them from parent's prototypes, I think the simplest version
is again description from 4.3.27.
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.
No, no, it's not required IMO. Because of dynamics, instances may have
own methods -- why not? And they are still methods, that is some action
which is _activated_ and has `this` as the instance.
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.
Object.getMethods(object) ->
var methods = {};
do {
for (var [propertyName, value] in
items(Object.getOwnPropertyNames(object)) if (typeof value == "function") {
methods[propertyName] = value;
}
} while (object = Object.getPrototypeOf(object));
return methods;
Objects.getMethods(foo).createBar.doc // shows description of createBar
function on foo object.
Don't know. Just one-of possible ways. E.g. it may consider only own
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.
Absolutely. Currently ES doesn't even have a _good console_ to try the
language. Once again, these two things as: (1) good auto-complete of
property names which is shown by pressing `tab` after dot property
accessor, and (2) the ability to get help information on the function
directly from the console -- help(parseInt) -> "Converts a string into a
num..." makes learning the language much quicker and fun.
I think you should think on implementing the sample version of ES -- the
ES itself and to spread it as downloadable binaries from the
ecmascript.org. Then people will just be able (1) to run it and pay in
the console learning the methods and properties of object, getting the
documentation right from here and (2) to attach the engine to favorite
editor and call it right from the editor by just pressing F5 and getting
output to the editors console back. There's no need to install Firefox
or Chrome first, go to their consoles, write there with inconvenient way
(or to copy-paste code from convenient editor to the inconvenient
Firebug's console and run).
Because now, to compile e.g. SpiderMonkey, it is required long process
with installing Mozilla-build, then to install many patches to VS
(because my 2005 compiler isn't supported anymore), etc. It doesn't
matter much of course, I can handle it. But it would be the best if
newcomers could just download ECMAScript (for Windows, Mac, Linux) and
just execute it. And already in the console to play with it and to get
the help directly and introspect meta-information, such as methods, etc.
Python did it. It's learned in a week max. Why not ES?
However, I don't necessarily think the a REPL model is the best exemplar for
such an environment.
Maybe, don't know. But the internal information on functions it's IMO
very good idea which implemented by Python. Moreover, that's said, the
good possibilities for auto-suggest and auto-complete based on the
doc-comment.
Also there can be real problems with exposing too much program metadata
directly to the application layer.
OTOH, yes, true.
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.
Regardless that unstratified meta-level is not a good idea, only it
allows to write the code in the shortest ways and without much of
syntactic "noise" and "garbage". But, seems we're talking about
stratified method -- Object.methods(obj), and not about obj.method.
However, that's said, I also don't see big practical applications of
this exact Object.methods(...), so comments and the cases are welcome,
so we have to think whether we even need it.
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
