ES4 draft: Object

Michael Daumling mdaeumli at adobe.com
Tue Mar 11 03:11:41 PDT 2008


I think that there is general agreement that

1) Object.prototype should not be polluted
2) Namespaces to add functionality are difficult to handle
3) Changing a getter to a setter by adding a new parameter is not a good
idea.

We will have this discussion over and over again as we add properties
and methods to Object and other classes. 

What if we considered a more ES3-like approach?

Let's bite the bullet and add *one* element to Object.prototype. This
element serves as a container for all future extensions. So, instead of

myObject.propertyIsEnumerable ("myProp", true);

use

myObject.__NameToBeDefined__.setPropertyEnumerable ("myProp", true);

This way, we reserve a "namespace", which in fact is an object, that can
take all of our current and future extensions without risking to Break
The Web.

Yes, I know that "this" inside setPropertyEnumerable() would usually not
refer to myObject, but to the __NameToBeDefined__ object. But since the
language owns that object, it could be declared final, and then, we
could add the changed behavior of "this" to the language implementation
without having to do anything else but mention that behavior in the
spec.

What do you think?

Michael
----------------------------------------------
 
-----Original Message-----
From: es4-discuss-bounces at mozilla.org
[mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Maciej Stachowiak
Sent: Monday, March 10, 2008 11:33 PM
To: Maciej Stachowiak
Cc: es4-discuss at mozilla.org
Subject: Re: ES4 draft: Object


On Mar 10, 2008, at 11:14 PM, Maciej Stachowiak wrote:

> The optional second argument to make propertyIsEnumerable a setter has

> some practical problems:
>
> 1) It violates the very strong norm that getter and setter functions 
> are separate and have their own different arguments. It will make the 
> feature harder to use and code using it harder to understand, to some 
> extent.
> 2) It makes it impossible to feature test for the ability to disable 
> enumerability, compared to a separate setter.
>
> Against the argument that it is too risky compatibility-wise to add a 
> new method to the object prototype (apparently the only reason things 
> were done), I propose that it is overblown. Mozilla has defined new 
> methods and properties on all objects. We have copied some in Safari 
> and seen no web compatibility issues, I assume Mozilla has not had any

> as well. Specifically, I am thinking of __defineSetter__, 
> __defineGetter__, __lookupSetter__, __lookupGetter__, and __proto__.
>
> Has any study been done on how many sites currently make use of the 
> property names of a likely setter for propertyIsEnumerable?

I forgot to mention, making two-argument propertyIsEnumerable have
setter semantics can be a tiny compatibility risk too, if any code
accidentally calls it with two args and does not expect it to act as a
setter in this case. Do we have any way to quantify the relative
compatibility risk of the current design vs. a separate setter?

Regards,
Maciej


_______________________________________________
Es4-discuss mailing list
Es4-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss



More information about the Es4-discuss mailing list