Approach of new Object methods in ES5

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Tue Apr 20 08:39:03 PDT 2010


On 17.04.2010 0:30, Tom Van Cutsem wrote:
>
>         The static methods are to avoid "breaking the web" by
>         injecting even
>         non-enumerable names into every object -- including the global
>         object --
>         via Object.prototype. Such injection can easily break
>         user-controlled
>         "object detection" done on colliding names.
>
>
>     I appreciate that. "Not breaking the web" seems to be the excuse
>     that everyone trots out when they introduce a kludge. I'm sure the
>     changes were necessary and I'll bow to my betters on this one.
>
>
> I don't see the ES5 Object API as a kludge at all.
> From a metaprogramming/reflection point-of-view, this API is very much 
> in line with the Mirror design principles outlined by Gilad Bracha and 
> Dave Ungar (see <http://bracha.org/mirrors.pdf>)
> The paper makes the case why you don't want to define all 'meta-level' 
> operations on the objects themselves. This architecture was used 
> successfully in Self and in JDI (the Java Debugger Interface).

Yes, it is. As I wrote, stratification for "meta" and "app" levels was a 
good reason in document mentioned at the beginning of this thread. But 
indeed, Java's implementation of this question (with mirror reflections) 
is just one of several. And this separation line can be smoothed. E.g. 
getting value of dynamically formed property name -- is it a /meta/ or 
/app/ operation? For example, Python treats it as meta:

getattr(bar, "foo")

In contrast, ES has for that purpose bracket notation property accessor, 
which is also /meta/ operation from this viewpoint. That means it 
supports introspection /embedded into the syntax/ without additional 
long intermediate operations, which makes its usage very convenient.

Should ES remove bracket notation (or change its meaning)? Who said 
that? Java?

String representation -- is it a /meta/ or /app/ operation? Python also 
has special "str" function (callable class) which takes responsibility 
for that (actually, calling internal __str__ method of an object).

But Java and ES treat it as object's method -- toString.

Getting /length/ of something -- is a meta or app operation? And so on, 
and so forth.



>         It might take the sting out if there were a way to curry the
>         leading
>         |obj| parameter as |this| that was cheaper than
>
>         Object.defineProperty(Object.prototype, 'keys', {value:
>         function () {
>         return Object.keys(this); }});
>
>
>     Why isn't defineProperty an instance method? It seems strange that
>     it is a static method.
>
>
> Imagine what Java would look like if all methods defined on 
> java.lang.Class were defined on java.lang.Object directly instead (and 
> would use 'this' instead of requiring an instance to be passed to 
> Method.invoke and Field.get). As you mentioned yourself: <quote>"One 
> of the things I always liked about JavaScript is that I didn't have to 
> remember a lot of things."</quote>
> The more stuff that's defined on objects by default, the more I have 
> to remember not to define a method called 'defineProperty' in my 
> application. Defining them 'outside of' the objects means most 
> Javascript programmers don't need to bother with these methods at all.

/Introspection/:

"foo" in bar
foo["bar" + "baz"]

for /each/ ( ... in ...) {...}

/Self-modification/:

foo.bar = function () {};
delete foo;

/Execution of dynamically generated code/:

Function("alert(ba" + (x ? "r" : "z") + ")")();

var foo = (function () {
   if (x) {
     return function () {alert(1);}
   } else {
     return function () {alert(2);}
   }
})()();

And so on.

How will it look in Java with its "Method.invoke" and "Field.get"? If it 
will take 10 intermediate actions for that -- could we send to hell such 
JavaScript then?

>
> Keystrokes matter, but you have to take into account the cognitive 
> overhead of remembering all inherited method names from some global 
> object as well.

Neither keystrokes, nor "I should remember much" matter here. Any good 
editor should support auto-complete and useful code snippets. This about 
ideology of a language. But, yeah, it is debatable what should be 
treated as /meta/ operation and should ES do it the way Java does -- 
with its long intermediate code.

But in general, the idea with mirrors is noble (and is used in some 
other languages, even in PHP; sorry for mention it agai ;)). Although I 
don't see a /huge/ advantage of this. In languages with dynamic mutable 
objects, introspection methods can be treated as just a /basic 
functionality/ of any object. And the /app/ level functionality -- is 
already an addition (some kind of invariants) with distinguishes these 
objects from others.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100420/e52ee3d9/attachment-0001.html>


More information about the es-discuss mailing list