isPropertyEnumerable is going to stay broken?

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

isPropertyEnumerable is going to stay broken?

Garrett Smith
https://bugzilla.mozilla.org/show_bug.cgi?id=57048

In this bug, dated 2000, Brendan and David agreed that
isPropertyEnumerable should check the prototype chain.

It should not backwards compatibility, but such functionality in the
language seems necessary. How to check enumerable attribute, including
the prototype chain?

http://wiki.ecmascript.org/doku.php?id=spec:chapter_19_native_objects#object_objects

Garrett

--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Garrett Smith
sorry, propertyIsEnumerable.



On 9/8/07, Garrett Smith <[hidden email]> wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=57048
>
> In this bug, dated 2000, Brendan and David agreed that
> isPropertyEnumerable should check the prototype chain.
>
> It should not backwards compatibility, but such functionality in the
> language seems necessary. How to check enumerable attribute, including
> the prototype chain?
>
> http://wiki.ecmascript.org/doku.php?id=spec:chapter_19_native_objects#object_objects
>
> Garrett
>
> --
> Programming is a collaborative art.
>


--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Brendan Eich-2
In reply to this post by Garrett Smith
On Sep 8, 2007, at 10:06 PM, Garrett Smith wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=57048
>
> In this bug, dated 2000, Brendan and David agreed that
> isPropertyEnumerable should check the prototype chain.

That was a long time ago, and while David Flanagan carries a lot of  
weight with many folks, he was not on ECMA TC39 TG1, and no one on  
the group changed the spec.

A lot of water under the bridge since then.

> It should not backwards compatibility,

Famous last words. :-)

We try to spider the web (Alexa top 1000 and the like) looking for  
counterexamples to such claims, and if we fail to find any, or  
better, we find instances of confusion where the incompatible fix is  
assumed (i.e., the JS author thought the spec worked the way we want  
to change it to work), then we have some confidence, but not much  
more, in favor of making an incompatible change. In general. In this  
case, no one has done such a scan. I'll see if I can get one started.

> but such functionality in the
> language seems necessary. How to check enumerable attribute, including
> the prototype chain?

Either reflect the __proto__ (read-only, please) property as some  
implementations do, or hardcode the prototype structure and code your  
propertyIsEnumerable tests accordingly.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

liorean
> On Sep 8, 2007, at 10:06 PM, Garrett Smith wrote:
> > but such functionality in the
> > language seems necessary. How to check enumerable attribute, including
> > the prototype chain?

On 10/09/2007, Brendan Eich <[hidden email]> wrote:
> Either reflect the __proto__ (read-only, please) property as some
> implementations do, or hardcode the prototype structure and code your
> propertyIsEnumerable tests accordingly.

Would it be possible to add an optional boolean parameter for
searching including the whole prototype chain, so that we get a
mechanism to do this that doesn't depend on implementation specifics
or code structure?
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Brendan Eich-2
On Sep 10, 2007, at 1:21 PM, liorean wrote:

> On 10/09/2007, Brendan Eich <[hidden email]> wrote:
>> Either reflect the __proto__ (read-only, please) property as some
>> implementations do, or hardcode the prototype structure and code your
>> propertyIsEnumerable tests accordingly.
>
> Would it be possible to add an optional boolean parameter for
> searching including the whole prototype chain, so that we get a
> mechanism to do this that doesn't depend on implementation specifics

The alternative above would standardize read-only __proto__, which  
would make that property no longer implementation-specific. But of  
course we have no proposal to do that.

> or code structure?

Adding another optional argument to propertyIsEnumerable is ugly,  
since ES4 has a long-standing proposal to add an optional boolean  
parameter for changing enumerability. Two trailing optional  
parameters, without named parameters, poses usability (both when  
writing code and reading it) hazards. Over-engineering with one  
optional object parameter, supporting "keyword" properties, seems bad  
too -- we want propertyIsEnumerable to remain simple, with few  
arguments in toto.

Is the ES3 behavior a true usability problem in the field, or more of  
a discordant spec glitch that we can live with?

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Garrett Smith
In reply to this post by Brendan Eich-2
On 9/10/07, Brendan Eich <[hidden email]> wrote:

> On Sep 10, 2007, at 1:28 PM, Garrett Smith wrote:
>
> > It's possible to crawl the prototype chain, true. I did not know some
> > implementations crawl the __proto__ for propertyIsEnumerable. Which
> > ones do this?
>
> None that I know of. That bug is old and SpiderMonkey was fixed way
> back then to follow ES3.
>
> > hasOwnProperty does not check the prototype chain
>
> That is what its name implies. That's necessary.
>
> > propertyIsEnumerable does not check the prototype chain
> > propertyIsEnumerable returns all enumerable properties in an object
> > instance
>
> You must mean "returns true for" in the last sentence above. I would
> say "obj.propertyIsEnumerable(id) returns true if id names a direct
> (own) enumerable property of obj".
>
yes:
propertyIsEnumerable returns true for all enumerable properties in an object

And my point was that it appears to duplicate functionality of
hasOwnProperty in a differently named method. The fact that the method
was called propertyIsEnumerable instead of isPropertyEnumerable is not
great, but the way propertyIsEnumerable is designed is confusing to
developers.

propertyIsEnumerable and hasOwnProperty are interchangeable (in
conforming hosts, not JScript)

> > All programmer defined values are enumerable (ES3)
> >
> > A conforming implementation of ES3 should see no difference between
> > propertyIsEnumerable and hasOwnProperty.
>
> But if we change propertyIsEnumerable to look up the prototype chain,
> and if a programmer defines a property on a prototype object, then
> the behavior of code that calls propertyIsEnumerable changes
> incompatibly -- it could break that programmer's code.
>

A useful and important feature.

> > @liorean -- time-warp reading your message...
>
> It looks like you replied only to me -- or did you reply-all and I'm
> missing headers on your message?
>
Ug. I'm retarded :P

Sorry

Garrett

> /be
>
>
>


--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Brendan Eich-2
On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:

> And my point was that it appears to duplicate functionality of
> hasOwnProperty in a differently named method.

The two functions are different:

js> var Op = Object.prototype;
js> Op.foo = 42;
42
js> print(Op.hasOwnProperty('foo'), Op.propertyIsEnumerable('foo'));
true true
js> print(Op.hasOwnProperty('toString'), Op.propertyIsEnumerable
('toString'));
true false

> The fact that the method
> was called propertyIsEnumerable instead of isPropertyEnumerable is not
> great, but the way propertyIsEnumerable is designed is confusing to
> developers.

I've never heard that complaint directly, or in a  
bugzilla.mozilla.org report. Can you cite complaints anywhere on the  
web? I believe you, but it would be good to have evidence.

> propertyIsEnumerable and hasOwnProperty are interchangeable (in
> conforming hosts, not JScript)

This statement is false.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Neil Mix
I think this is what Garrett is referring to:

js> function f() {}
js> f.prototype.foo = "blah";
blah
js> var x = new f();
js> print(x.propertyIsEnumerable("foo"));
false
js> for (var n in x) print(n);
foo

And I have to agree with him, the method is confusing.  Based on its  
name, I'd expect it to return true if the property can be enumerated  
via for-in loop on the given object, regardless of where the property  
exists in the prototype chain.


On Sep 10, 2007, at 4:27 PM, Brendan Eich wrote:

> On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:
>
>> And my point was that it appears to duplicate functionality of
>> hasOwnProperty in a differently named method.
>
> The two functions are different:
>
> js> var Op = Object.prototype;
> js> Op.foo = 42;
> 42
> js> print(Op.hasOwnProperty('foo'), Op.propertyIsEnumerable('foo'));
> true true
> js> print(Op.hasOwnProperty('toString'), Op.propertyIsEnumerable
> ('toString'));
> true false
>
>> The fact that the method
>> was called propertyIsEnumerable instead of isPropertyEnumerable is  
>> not
>> great, but the way propertyIsEnumerable is designed is confusing to
>> developers.
>
> I've never heard that complaint directly, or in a
> bugzilla.mozilla.org report. Can you cite complaints anywhere on the
> web? I believe you, but it would be good to have evidence.
>
>> propertyIsEnumerable and hasOwnProperty are interchangeable (in
>> conforming hosts, not JScript)
>
> This statement is false.
>
> /be
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Garrett Smith
In reply to this post by Brendan Eich-2
On 9/10/07, Brendan Eich <[hidden email]> wrote:

> On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:
>
> > And my point was that it appears to duplicate functionality of
> > hasOwnProperty in a differently named method.
>
> The two functions are different:
>
> js> var Op = Object.prototype;
> js> Op.foo = 42;
> 42
> js> print(Op.hasOwnProperty('foo'), Op.propertyIsEnumerable('foo'));
> true true
> js> print(Op.hasOwnProperty('toString'), Op.propertyIsEnumerable
> ('toString'));
> true false
>
> > The fact that the method
> > was called propertyIsEnumerable instead of isPropertyEnumerable is not
> > great, but the way propertyIsEnumerable is designed is confusing to
> > developers.
>
> I've never heard that complaint directly, or in a
> bugzilla.mozilla.org report. Can you cite complaints anywhere on the
> web? I believe you, but it would be good to have evidence.
>
> > propertyIsEnumerable and hasOwnProperty are interchangeable (in
> > conforming hosts, not JScript)
>
> This statement is false.
>
You're example clarifies that. I see how it could be useful, in fact,
for examining a prototype chain to filter out extra stuff that got
shoved in.

For user-defined objects, propertyIsEnumerable and hasOwnProperty are
interchangeable.

var obj = {
    Garrett : "monkeybrains"
    ,borked : "javascript" // transitivity fixed :-)
    ,toString : function() { return "an enumerable prop"; }
    ,valueOf : function() { return 2; } // also enumerable.
};

Is there a value for s where the following is true:
(obj.hasOwnProperty( s ) != obj.propertyIsEnumerable( s ))

Garrett

> /be
>


--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Brendan Eich-2
In reply to this post by Neil Mix
On Sep 10, 2007, at 2:41 PM, Neil Mix wrote:

> I think this is what Garrett is referring to:
>
> js> function f() {}
> js> f.prototype.foo = "blah";
> blah
> js> var x = new f();
> js> print(x.propertyIsEnumerable("foo"));
> false
> js> for (var n in x) print(n);
> foo
>
> And I have to agree with him, the method is confusing.

Sure, but that ship sailed (https://bugzilla.mozilla.org/show_bug.cgi?
id=57048#c4).

> Based on its
> name, I'd expect it to return true if the property can be enumerated
> via for-in loop on the given object, regardless of where the property
> exists in the prototype chain.

My question remains: is this an incompatible change that will help  
more than it hurts, and otherwise be worth making?

Even with the change, hasOwnProperty and propertyIsEnumerable are  
different, but from Garrett's latest mail it's clear that we agree  
they're functionally the same for most user-defined properties in  
their directly-owning objects.

Enumerability is a weak concept. I wish I'd left it out back in 1995,  
when I was over-minimizing elsewhere.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

__proto__

Kris Zyp-2
In reply to this post by Brendan Eich-2
> The alternative above would standardize read-only __proto__, which  would
> make that property no longer implementation-specific. But of  course we
> have no proposal to do that.
I realize this wasn't really the main subject... but could the __proto__
property be defined in the spec (as readonly)? I would love to see that
property standardized.
Kris

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: __proto__

Lars T Hansen-2
On the one hand, __proto__ is another potential security hole, and it
prevents implementations from sharing prototype objects among multiple
documents -- the link may be read-only but the object isn't.  Function
B called from function A with object O may hack O.__proto__ and A can
do nothing about it; suddenly all O-like objects in the system act
differently.

On the other hand, Constructor.prototype is generally available for
any Constructor, so it's hard to see what the real damage is -- it's
not obviously worse than some other aspects of the language.

On the third hand, some implementations may have specialized objects
for which no Constructor is available and for whom keeping
[[Prototype]] unavailable is desirable.  Similarly, some toolkits may
have private prototype objects that are not available to client code
because the constructor is hidden in a lexical scope (ES3) or
package/namespace (ES4).

Introspection is great, but it assumes a lot about how trust works in
the environment.

--lars


On 9/11/07, Kris Zyp <[hidden email]> wrote:

> > The alternative above would standardize read-only __proto__, which  would
> > make that property no longer implementation-specific. But of  course we
> > have no proposal to do that.
> I realize this wasn't really the main subject... but could the __proto__
> property be defined in the spec (as readonly)? I would love to see that
> property standardized.
> Kris
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: __proto__

liorean
On 11/09/2007, Lars T Hansen <[hidden email]> wrote:

> On the one hand, __proto__ is another potential security hole, and it
> prevents implementations from sharing prototype objects among multiple
> documents -- the link may be read-only but the object isn't.  Function
> B called from function A with object O may hack O.__proto__ and A can
> do nothing about it; suddenly all O-like objects in the system act
> differently.
>
> On the other hand, Constructor.prototype is generally available for
> any Constructor, so it's hard to see what the real damage is -- it's
> not obviously worse than some other aspects of the language.

For ES3 code, exposing __proto__ means that prototypes on constructors
protected by scope (as is becoming practice by at least library
writers today) are exposed, which they weren't before. It also means
that a prototype that is thrown away after setting up the object will
now be accessible.

> On the third hand, some implementations may have specialized objects
> for which no Constructor is available and for whom keeping
> [[Prototype]] unavailable is desirable.  Similarly, some toolkits may
> have private prototype objects that are not available to client code
> because the constructor is hidden in a lexical scope (ES3) or
> package/namespace (ES4).
>
> Introspection is great, but it assumes a lot about how trust works in
> the environment.

Hmm. On another note: Would it be reasonable to standardise a way to
attach a prototype chain to a plain object instanciator? (Instead of
reading one out of an object...)


    var
        someObject={
            mySharedValue: value},
        someOtherObject={
            "[[prototype]]": someObject};

This would get rid of the need for a function call (Crockford's object
function for instance) for setting up plain ES3 prototypal
inheritance, and would mean some structures that are not currently
serialisable as JSON despite being plain value structures would become
serialisable.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: __proto__

Lars T Hansen-2
On 9/11/07, liorean <[hidden email]> wrote:

> On 11/09/2007, Lars T Hansen <[hidden email]> wrote:
> > On the one hand, __proto__ is another potential security hole, and it
> > prevents implementations from sharing prototype objects among multiple
> > documents -- the link may be read-only but the object isn't.  Function
> > B called from function A with object O may hack O.__proto__ and A can
> > do nothing about it; suddenly all O-like objects in the system act
> > differently.
> >
> > On the other hand, Constructor.prototype is generally available for
> > any Constructor, so it's hard to see what the real damage is -- it's
> > not obviously worse than some other aspects of the language.
>
> For ES3 code, exposing __proto__ means that prototypes on constructors
> protected by scope (as is becoming practice by at least library
> writers today) are exposed, which they weren't before.

OK, that's the problem I was alluding to in my "on the third hand".

> It also means
> that a prototype that is thrown away after setting up the object will
> now be accessible.

That I don't get.  The object is the prototype object of some other
object, the garbage collector can't collect the proto until the
referencing object can be collected.  It's pretty clear to me that you
can't fold the prototype into the object itself without a lot of extra
machinery.  Perhaps you can provide a concrete example?

> > On the third hand, some implementations may have specialized objects
> > for which no Constructor is available and for whom keeping
> > [[Prototype]] unavailable is desirable.  Similarly, some toolkits may
> > have private prototype objects that are not available to client code
> > because the constructor is hidden in a lexical scope (ES3) or
> > package/namespace (ES4).
> >
> > Introspection is great, but it assumes a lot about how trust works in
> > the environment.
>
> Hmm. On another note: Would it be reasonable to standardise a way to
> attach a prototype chain to a plain object instanciator? (Instead of
> reading one out of an object...)
>
>
>     var
>         someObject={
>             mySharedValue: value},
>         someOtherObject={
>             "[[prototype]]": someObject};
>
> This would get rid of the need for a function call (Crockford's object
> function for instance) for setting up plain ES3 prototypal
> inheritance, and would mean some structures that are not currently
> serialisable as JSON despite being plain value structures would become
> serialisable.

I can't argue about the serialization bit.

I love to argue about performance, though, so I'll take your "get rid
of the need for a function call" as an argument about performance and
proceed from there :)

If function calls are so expensive that they dominate object creation
time we should worry about how we can make them faster, I think,
especially if the language gets in the way of good performance.  It's
true function calls are a little heavyweight in ES...

A quick test comparing 0-argument function calls to allocation of
empty objects using {} syntax follows.  Results are reported as the
number of calls that can be made in the time it takes to perform one
allocation.

On a MacBook Pro:

                              calls per alloc
   Opera 9.5a1     3.48
   Opera 9.2          0.66
   Safari 2              0.68

On a Thinkpad T60p:

  FF 2.0.0.6          2.88
  IE 6                     1.27 (at 1/10 the number of iterations
because of the silly "slow script" dialog)

This probably includes a little GC time for the allocation test but
that doesn't seem unfair.  Test code included below.

This simplistic test indicates that some browsers (Opera 9.2, Safari
2) have particularly slow calls relative to allocations and so your
concern may well be warranted.  But if Safari 3 and to a lesser extent
IE 7 perform better, the overhead of a call may not be much to worry
about.

Obviously the test completely ignores the fact that, say, calls in
Safari may be much faster than in another browser, it may just be that
the allocator is superfast too, at which point the ratio is not very
relevant.  (That does not seem to be the case, though.  The browsers
are all pretty much comparable.  The big change for Opera is explained
by allocation running at half the speed in 9.5 while calls are much
faster.)

--lars

function g() {}

function testalloc() {
    var x;
    for ( var i=0 ; i < 1000000 ; i++ ) {
        x = {};
    }
}

function testcall() {
    var x;
    for ( var i=0 ; i < 1000000 ; i++ ) {
        g();
    }
}

var t1 = new Date;
testalloc();
var t2 = new Date;
testcall();
var t3 = new Date;
document.writeln("Calls per alloc = " + 1/((t3 - t2)/(t2 - t1)));


> --
> David "liorean" Andersson
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: __proto__

liorean
> On 9/11/07, liorean <[hidden email]> wrote:
> > It also means
> > that a prototype that is thrown away after setting up the object will
> > now be accessible.

On 11/09/2007, Lars T Hansen <[hidden email]> wrote:
> That I don't get.  The object is the prototype object of some other
> object, the garbage collector can't collect the proto until the
> referencing object can be collected.  It's pretty clear to me that you
> can't fold the prototype into the object itself without a lot of extra
> machinery.  Perhaps you can provide a concrete example?

Not anything in production code. Conceptually:

    function F(){}
    /* add some prototype properties here */
    newObj=new F;
    F.prototype={constructor:F};

That way, you've protected the newObj.[[prototype]] object from being
modified by throwing it away - the only reference to it is from
newObj, and that one isn't exposed. The usefulness of doing this
instead of using scope is not obvious to me, however, it was just
another case of how to make a [[prototype]] unaccessible from the
normal language mechanics that I could think of.


> On 9/11/07, liorean <[hidden email]> wrote:
> > This would get rid of the need for a function call (Crockford's object
> > function for instance) for setting up plain ES3 prototypal
> > inheritance, and would mean some structures that are not currently
> > serialisable as JSON despite being plain value structures would become
> > serialisable.

On 11/09/2007, Lars T Hansen <[hidden email]> wrote:
> I can't argue about the serialization bit.
>
> I love to argue about performance, though, so I'll take your "get rid
> of the need for a function call" as an argument about performance and
> proceed from there :)

Actually, it's not performance that I was thinking of. I just prefer
the option of making the prototype relation declarative in a JSON-like
initialiser (obviously we need variable names for it to work, so it
wouldn't be *entirely* compatible with current JSON) instead of
requiring a call to a function where the only thing the function call
would be there to do is to set up a reference to a prototype object.
Not only do you need to do the call, by the way, you also need to
change from object instanciator to member assignments.

It's mostly about giving the scenario a clean looking code. Contrast
the following:

    function inheritFrom(o){
        function F(){}
        F.prototype=o;
        return new F;
    }
    var
        a={ /* declare some properties*/ },
        b=inheritFrom(a);
    b['prop0']='blah';
    b['prop1']='blah';
    /* ... */

to the following:

    var
        a={ /* declare some properties*/ },
        b={
            "[[Prototype]]": a,
            prop0: 'blah',
            prop1: 'bleh'};

I would consider being able to keep using the object instanciator when
you want to set up a relation like that a real plus when it comes to
code clarity.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: __proto__

Kris Zyp-2
In reply to this post by Lars T Hansen-2
Is __proto__ somehow a new security threat? __proto__ has been around for
ages in SM/FF and not only that, but it has been there in the more hazardous
writable form. I just wanted it be actually included in the spec. Or is
there some new functionality in ES4 that will somehow interact with
__proto__ to introduce a security threat?
Kris
----- Original Message -----
From: "Lars T Hansen" <[hidden email]>
To: "Kris Zyp" <[hidden email]>
Cc: "Brendan Eich" <[hidden email]>; "liorean" <[hidden email]>;
<[hidden email]>
Sent: Tuesday, September 11, 2007 2:34 AM
Subject: Re: __proto__


> On the one hand, __proto__ is another potential security hole, and it
> prevents implementations from sharing prototype objects among multiple
> documents -- the link may be read-only but the object isn't.  Function
> B called from function A with object O may hack O.__proto__ and A can
> do nothing about it; suddenly all O-like objects in the system act
> differently.
>
> On the other hand, Constructor.prototype is generally available for
> any Constructor, so it's hard to see what the real damage is -- it's
> not obviously worse than some other aspects of the language.
>
> On the third hand, some implementations may have specialized objects
> for which no Constructor is available and for whom keeping
> [[Prototype]] unavailable is desirable.  Similarly, some toolkits may
> have private prototype objects that are not available to client code
> because the constructor is hidden in a lexical scope (ES3) or
> package/namespace (ES4).
>
> Introspection is great, but it assumes a lot about how trust works in
> the environment.
>
> --lars
>
>
> On 9/11/07, Kris Zyp <[hidden email]> wrote:
>> > The alternative above would standardize read-only __proto__, which
>> > would
>> > make that property no longer implementation-specific. But of  course we
>> > have no proposal to do that.
>> I realize this wasn't really the main subject... but could the __proto__
>> property be defined in the spec (as readonly)? I would love to see that
>> property standardized.
>> Kris
>>
>> _______________________________________________
>> Es4-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es4-discuss
>>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: __proto__

Lars T Hansen-2
__proto__ breaks abstraction boundaries in the language -- it's just
like function.caller, you get to look at and change objects that your
caller may wish to keep secret from you.  Whether it's actually a
security threat depends on the details of the environment: whether
your caller fits those criteria or not, or whether your run-time
environment has objects whose constructors are not exposed to client
code.

--lars

On 9/11/07, Kris Zyp <[hidden email]> wrote:

> Is __proto__ somehow a new security threat? __proto__ has been around for
> ages in SM/FF and not only that, but it has been there in the more hazardous
> writable form. I just wanted it be actually included in the spec. Or is
> there some new functionality in ES4 that will somehow interact with
> __proto__ to introduce a security threat?
> Kris
> ----- Original Message -----
> From: "Lars T Hansen" <[hidden email]>
> To: "Kris Zyp" <[hidden email]>
> Cc: "Brendan Eich" <[hidden email]>; "liorean" <[hidden email]>;
> <[hidden email]>
> Sent: Tuesday, September 11, 2007 2:34 AM
> Subject: Re: __proto__
>
>
> > On the one hand, __proto__ is another potential security hole, and it
> > prevents implementations from sharing prototype objects among multiple
> > documents -- the link may be read-only but the object isn't.  Function
> > B called from function A with object O may hack O.__proto__ and A can
> > do nothing about it; suddenly all O-like objects in the system act
> > differently.
> >
> > On the other hand, Constructor.prototype is generally available for
> > any Constructor, so it's hard to see what the real damage is -- it's
> > not obviously worse than some other aspects of the language.
> >
> > On the third hand, some implementations may have specialized objects
> > for which no Constructor is available and for whom keeping
> > [[Prototype]] unavailable is desirable.  Similarly, some toolkits may
> > have private prototype objects that are not available to client code
> > because the constructor is hidden in a lexical scope (ES3) or
> > package/namespace (ES4).
> >
> > Introspection is great, but it assumes a lot about how trust works in
> > the environment.
> >
> > --lars
> >
> >
> > On 9/11/07, Kris Zyp <[hidden email]> wrote:
> >> > The alternative above would standardize read-only __proto__, which
> >> > would
> >> > make that property no longer implementation-specific. But of  course we
> >> > have no proposal to do that.
> >> I realize this wasn't really the main subject... but could the __proto__
> >> property be defined in the spec (as readonly)? I would love to see that
> >> property standardized.
> >> Kris
> >>
> >> _______________________________________________
> >> Es4-discuss mailing list
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es4-discuss
> >>
>
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Neil Mix
In reply to this post by Brendan Eich-2
>> And I have to agree with him, the method is confusing.
>
> Sure, but that ship sailed (https://bugzilla.mozilla.org/show_bug.cgi?
> id=57048#c4).

I was responding to the following interchange:
Garrett: ...but the way propertyIsEnumerable is designed is confusing  
to developers.
Brendan: I've never heard that complaint directly, or in a  
bugzilla.mozilla.org report. Can you cite complaints anywhere on the  
web? I believe you, but it would be good to have evidence.

My opinion of the propertyIsEnumerable method was derived from  
personal experience, prior to this discussion.  Purely FWIW, if that  
counts as "evidence."

> My question remains: is this an incompatible change that will help
> more than it hurts, and otherwise be worth making?

If we were voting, I'd vote "yes."  If you're asking for objectivity,  
I think your crawlers provide the only reliable data.  (Searching for  
"propertyIsEnumerable filetype:js" on Google yields no hits.)
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: isPropertyEnumerable is going to stay broken?

Bob Clary
Neil Mix wrote:

>
> If we were voting, I'd vote "yes."  If you're asking for objectivity,  
> I think your crawlers provide the only reliable data.  (Searching for  
> "propertyIsEnumerable filetype:js" on Google yields no hits.)

Ok. I'll kick off a scan looking for instances of propertyisEnumerable.
While I am at it, are there any other constructs people are interested
in that I can bundle with this run?

bc

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Fwd: isPropertyEnumerable is going to stay broken?

Garrett Smith
In reply to this post by Brendan Eich-2
(fwd to list)...
On 9/10/07, Brendan Eich <[hidden email]> wrote:

> On Sep 10, 2007, at 2:41 PM, Neil Mix wrote:
>
> > I think this is what Garrett is referring to:
> >
> > js> function f() {}
> > js> f.prototype.foo = "blah";
> > blah
> > js> var x = new f();
> > js> print(x.propertyIsEnumerable("foo"));
> > false
> > js> for (var n in x) print(n);
> > foo
> >
> > And I have to agree with him, the method is confusing.
>
> Sure, but that ship sailed (https://bugzilla.mozilla.org/show_bug.cgi?
> id=57048#c4).
>
> > Based on its
> > name, I'd expect it to return true if the property can be enumerated
> > via for-in loop on the given object, regardless of where the property
> > exists in the prototype chain.
>
> My question remains: is this an incompatible change that will help
> more than it hurts, and otherwise be worth making?
>
Probably have more important things in the language.

I read that bug rep't and you stated in the last comment "I still
think ECMA is wrong, and should be fixed."

I'm considering your question.

I would like it to be fixed, but can't say if it's the Right Thing.
I'll consider brining it up on c.l.j

I'm going to make a blog entry about it, too.

Garrett
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12