Le 21/12/2012 20:19, Tom Van Cutsem a écrit :
Given that there are plenty of cases where the configurable:true
contract is violated (i.e. non-deletable configurable properties),
and that it is still possible to fix the 3 violations of the
configurable:false contract, I think I'm swayed to
Given that there are plenty of cases where the configurable:true contract
is violated (i.e. non-deletable configurable properties), and that it is
still possible to fix the 3 violations of the configurable:false contract,
I think I'm swayed to simply go for configurable:true getters/setters that
2012/12/19 David Bruant bruan...@gmail.com
Le 19/12/2012 17:34, Brandon Benvie a écrit :
So the remaining situations in which it's difficult are in the parent
frame when you want to do this one of the handful of properties that have
this treatment.
An option that might have uses in other
Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
2012/12/19 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 19/12/2012 17:34, Brandon Benvie a écrit :
So the remaining situations in which it's difficult are in
the parent frame when you want to do this one of the
2012/12/20 David Bruant bruan...@gmail.com
Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
I think I'm leaning towards non-configurable accessors with deep-frozen
(null-realm) getter/setter functions.
Brandon's point about the fact that it really is the matter of a few
properties made me
Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
2012/12/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
I think I'm leaning towards non-configurable accessors with
deep-frozen (null-realm) getter/setter functions.
In Chrome (WebKit in general maybe?) there are already plenty of examples
of violating the convention configurable: true means deletable. For
example, attempting to delete any of the hundreds DOM interfaces that are
present on the WindowProxy does nothing. Using defineProperty to overwrite
them
2012/12/20 David Bruant bruan...@gmail.com
Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
Mark supports this view to enable reasoning about code of the form:
if ( ! Object.getOwnPropertyDescriptor(obj, foo).configurable) {
host objects (or proxies) could omit .configurable or make it any
My intuition, I now realize just assumption, was that most/all invariant
guarantees were one way. That is: { configurable: true } specifically does
not guarantee anything (although I guess that's a kind of guarantee).
Either way, it is intuitive for me that something that is configurable says
Le 20/12/2012 18:51, Tom Van Cutsem a écrit :
2012/12/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
Mark supports this view to enable reasoning about code of the form:
if ( ! Object.getOwnPropertyDescriptor(obj,
2012/12/15 David Bruant bruan...@gmail.com
Hi,
ES5 invariants are silent when it comes to function identity of
non-configurable accessors. That is, for a given object o,
Object.**getOwnPropertyDescriptor(o, 'a').get ===
Object.**getOwnPropertyDescriptor(o,
'a').get
(two seperate
2012/12/18 Allen Wirfs-Brock al...@wirfs-brock.com
On Dec 18, 2012, at 9:08 AM, Brendan Eich wrote:
Mark S. Miller wrote:
That could work, but because of its complexity, I'm leaning back towards
the configurable data property that refuses to be configured approach. Is
there a problem with
On 18 December 2012 20:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
To me, as a application programmer or even a library programmer,
enforcement of these invariants are generally unnecessary. If enforcement
impacts performance or expressibility they have a negative impact on my
ability
2012/12/18 Mark S. Miller erig...@google.com
I see no reason why this needs to be a reflected property. As to
whether it is an exotic internal property or just prose, that is a
specification expository issue for which I defer to Allen. But the
spec only needs such extra state for the exotic
Le 19/12/2012 14:38, Tom Van Cutsem a écrit :
I too find the solution of non-configurable data properties
masquerading as configurable data properties bothersome. We have a
mechanism in place for describing the behavior of ES5 properties, yet
here is a case where we can't be honest about a
That's easily solved by making the accessor have a null prototype and
frozen though.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Le 19/12/2012 16:34, Brandon Benvie a écrit :
That's easily solved by making the accessor have a null prototype and
frozen though.
True, but it makes that you can't re-apply these getters and setters
with .call.
Since the getter doesn't inherit from Function.prototype any longer, you
have to
didn't know about that custom possibility so yes, I guess we are OK here,
thanks for the update.
br
On Wed, Dec 19, 2012 at 5:54 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/12/18 Mark S. Miller erig...@google.com
I see no reason why this needs to be a reflected property. As to
It only has to be a handful of accessors, no? I was thinking basically of
just the few things on the global object that need this treatment.
location, document, window, navigator, maybe a few others? And location is
the only one with a setter, so we're mostly just talking about getters on
the
Also note that none of these properties are currently accessors so no one
has come to rely on being able to extract their getters. So introducing
them with neutered accessors would not have an impact on existing code.
On Wednesday, December 19, 2012, Brandon Benvie wrote:
It only has to be a
Le 19/12/2012 17:34, Brandon Benvie a écrit :
Also note that none of these properties are currently accessors so no
one has come to rely on being able to extract their getters. So
introducing them with neutered accessors would not have an impact on
existing code.
I fully agree. I wasn't
[Reposted at David's request.]
-- Forwarded message --
From: Mark S. Miller erig...@google.com
Date: Tue, Dec 18, 2012 at 8:19 AM
Subject: Re: Function identity of non-configurable accessors
To: David Bruant bruan...@gmail.com
On Tue, Dec 18, 2012 at 8:08 AM, David Bruant bruan
Hi,
Le 18/12/2012 18:08, Brendan Eich a écrit :
Mark S. Miller wrote:
That could work, but because of its complexity, I'm leaning back
towards the configurable data property that refuses to be
configured approach. Is there a problem with that? It self-hosts fine.
Certainly this is the
On Dec 15, 2012, at 2:51 PM, David Bruant wrote:
Le 15/12/2012 16:14, David Bruant a écrit :
Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
If I create a non-configurable property with a getter that I define (such
as `() = 3`), I know that accessing the property will always produce
a
On Dec 18, 2012, at 9:08 AM, Brendan Eich wrote:
Mark S. Miller wrote:
That could work, but because of its complexity, I'm leaning back towards the
configurable data property that refuses to be configured approach. Is
there a problem with that? It self-hosts fine.
Certainly this is the
On Tue, Dec 18, 2012 at 9:38 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The whole whole idea of such invariants was a late addition to ES5, and not
without some controversy. I don't think anyone believed that ES5 had a
complete set of invariants or even what that might be.
As part
On Tue, Dec 18, 2012 at 10:23 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If we are only talking about the Global Object, we can probably accommodate
almost anything by defining it as a special kind of exotic object.
AFAICT, we are only talking about the global object, in order to deal
{deletable: false} does not look that bad, semantically speaking ... you
don't have to explain much what that would do in a property descriptor.
Thing is, all others are false by default so you might want to chose same
default for this property and in this case the name is wrong.
I see no reason why this needs to be a reflected property. As to
whether it is an exotic internal property or just prose, that is a
specification expository issue for which I defer to Allen. But the
spec only needs such extra state for the exotic global object. There's
nothing general about it.
On Dec 18, 2012, at 10:34 AM, Mark S. Miller wrote:
On Tue, Dec 18, 2012 at 9:38 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The whole whole idea of such invariants was a late addition to ES5, and not
without some controversy. I don't think anyone believed that ES5 had a
complete
Hi,
ES5 invariants are silent when it comes to function identity of
non-configurable accessors. That is, for a given object o,
Object.getOwnPropertyDescriptor(o, 'a').get ===
Object.getOwnPropertyDescriptor(o, 'a').get
(two seperate calls) is not guaranteed.
The built
On Sat, Dec 15, 2012 at 9:27 AM, David Bruant bruan...@gmail.com wrote:
The way things are going, WindowProxy [Unforgeable] properties will be
non-configurable getters. If, upon underlying window change, the WindowProxy
is expected to keep the exact same getter function, then, it may result in
Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
On Sat, Dec 15, 2012 at 9:27 AM, David Bruant bruan...@gmail.com wrote:
The way things are going, WindowProxy [Unforgeable] properties will be
non-configurable getters. If, upon underlying window change, the WindowProxy
is expected to keep the
David Bruant wrote:
If I create a non-configurable property with a getter that I define
(such
as `() = 3`), I know that accessing the property will always produce
a known value.Relaxing this restriction means that proxies could
produce whatever they wanted in this situation.
Indeed. Note
Le 15/12/2012 19:11, Brendan Eich a écrit :
David Bruant wrote:
If I create a non-configurable property with a getter that I define
(such
as `() = 3`), I know that accessing the property will always produce
a known value.Relaxing this restriction means that proxies could
produce whatever
David Bruant wrote:
Le 15/12/2012 19:11, Brendan Eich a écrit :
David Bruant wrote:
If I create a non-configurable property with a getter that I define
(such
as `() = 3`), I know that accessing the property will always produce
a known value.Relaxing this restriction means that proxies
Is there any leak if you set the accessor functions to have a null
[[Prototype]] and to have no non-primitive properties?
On Sat, Dec 15, 2012 at 4:20 PM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
Le 15/12/2012 19:11, Brendan Eich a écrit :
David Bruant wrote:
If I
Le 15/12/2012 22:20, Brendan Eich a écrit :
David Bruant wrote:
Le 15/12/2012 19:11, Brendan Eich a écrit :
Frozen accessors would be best if we can get away with the
incompatibility.
I've given more thought. Frozen accessors can't be a solution. Only
deeply frozen would be.
Oh sure -- that
Le 15/12/2012 22:26, Brandon Benvie a écrit :
Is there any leak if you set the accessor functions to have a null
[[Prototype]] and to have no non-primitive properties?
There isn't. That would be the super-minimal null realm solution.
David
On Sat, Dec 15, 2012 at 4:20 PM, Brendan Eich
Le 15/12/2012 16:14, David Bruant a écrit :
Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
If I create a non-configurable property with a getter that I define
(such
as `() = 3`), I know that accessing the property will always produce
a known value.Relaxing this restriction means that
40 matches
Mail list logo
