On Jun 22, 2011, at 3:55 PM, Axel Rauschmayer wrote:
>> You should not in general mutate shared prototype state via one of N
>> delegating objects. It leads to trouble.
>
> What’s the difference to a global variable?
The list is long.
How about this? You have a bunch of local variables in vari
On Jun 22, 2011, at 4:02 PM, Axel Rauschmayer wrote:
>> From: Brendan Eich
>> Date: June 23, 2011 0:21:17 GMT+02:00
>>
>>> Is there no per-call cost whatsoever to adding static super?
>>
>> No, it's static -- an internal property of the function object set once on
>> creation and (in my view)
On Tue, Jun 21, 2011 at 7:23 PM, Allen Wirfs-Brock wrote:
> ES5.1:
> 7.6.1 Reserved Words
>
> A reserved word is an *IdentifierName* that cannot be used as an *
> Identifier*.
>
Descriptive.
>
> 7.6Identifier Names and Identifiers
>
> Identifier Names are tokens that are inte
> From: Brendan Eich
> Date: June 23, 2011 0:21:17 GMT+02:00
>
>> Is there no per-call cost whatsoever to adding static super?
>
> No, it's static -- an internal property of the function object set once on
> creation and (in my view) never changed thereafter unless unobservably
> (Allen's poin
> You should not in general mutate shared prototype state via one of N
> delegating objects. It leads to trouble.
What’s the difference to a global variable? I always thought about an instance
in JavaScript as being composed of a non-shared object and a shared
meta-object. Why should the former
On Jun 22, 2011, at 2:37 PM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 2:11 PM, Brendan Eich wrote:
>> On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
>>
>>> On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
>>> wrote:
Can the value of a dynamic super be unambiguously resolved with p
On Jun 22, 2011, at 2:36 PM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 2:10 PM, Brendan Eich wrote:
>>> Yes, functions have static scope, but functions (and all objects) do
>>> not have static owning objects,
>> The scope in ES1-5 can be an object, the global object. Your use of "owning"
>> he
On Wed, Jun 22, 2011 at 2:11 PM, Brendan Eich wrote:
> On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
>
>> On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
>> wrote:
>>> Can the value of a dynamic super be unambiguously resolved with prototype
>>> climbing and without an extra implicit para
On Wed, Jun 22, 2011 at 2:10 PM, Brendan Eich wrote:
>> Yes, functions have static scope, but functions (and all objects) do
>> not have static owning objects,
> The scope in ES1-5 can be an object, the global object. Your use of "owning"
> here either covers that case, in which your claim is fal
On Wed, Jun 22, 2011 at 3:01 PM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
> wrote:
> > Can the value of a dynamic super be unambiguously resolved with prototype
> > climbing and without an extra implicit parameter?
>
> Yes, it can be unambiguously determined by p
On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
> wrote:
>> Can the value of a dynamic super be unambiguously resolved with prototype
>> climbing and without an extra implicit parameter?
>
> Yes, it can be unambiguously determined by protot
On Jun 22, 2011, at 9:01 AM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 10:35 AM, Brendan Eich wrote:
>> Functions have static scope (see the [[Scope]] internal property). This is
>> absolute and with very good reason!
>
> Yes, functions have static scope, but functions (and all objects) do
>
We haven't actually revisited the membrane code in light of the fixed
properties strawman.
One change that I can imagine being made, is that a membrane wrapper, when
first created, explicitly copies over the non-configurable properties of its
target (this is similar to what the "wrap" method does
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
wrote:
> Can the value of a dynamic super be unambiguously resolved with prototype
> climbing and without an extra implicit parameter?
Yes, it can be unambiguously determined by prototype climbing, the
only information from the call site that
On Wed, Jun 22, 2011 at 12:33 PM, Peter Michaux wrote:
> I agree that dynamic "this" but static "super" seems odd but maybe
> symmetry with "this" is not desired. Maybe we should have static
> "super" and be looking for symmetry with a static "self".
Symmetry with |this| is important because |sup
On Wed, Jun 22, 2011 at 8:28 AM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich wrote:
>> On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
>>
>>> I don't think we need any "safety check" when assigning a method or
>>> accessor getter or setter that uses super to an object. The
On Wed, Jun 22, 2011 at 1:01 PM, Sean Eagan wrote:
> Its value is already resolved via prototype climbing, I don't see the
> tremendous cost is simply making this value accessible within the
> function activation which occurs as a result of the prototype
> climbing.
Can the value of a dynamic
On Wed, Jun 22, 2011 at 10:35 AM, Brendan Eich wrote:
> Functions have static scope (see the [[Scope]] internal property). This is
> absolute and with very good reason!
Yes, functions have static scope, but functions (and all objects) do
not have static owning objects, they are free to be passed
On Jun 22, 2011, at 8:28 AM, Sean Eagan wrote:
> On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich wrote:
>> On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
>>
>>> I don't think we need any "safety check" when assigning a method or
>>> accessor getter or setter that uses super to an object. The con
On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich wrote:
> On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
>
>> I don't think we need any "safety check" when assigning a method or
>> accessor getter or setter that uses super to an object. The concept
>> of "super" seems to be a relative one,
>
> That
On Wed, Jun 22, 2011 at 9:23 AM, Axel Rauschmayer wrote:
> From: Sean Eagan
> Date: June 22, 2011 15:48:18 GMT+02:00
>
> There is no infinite recursion hazard in the semantics that Axel
> suggested, and that I used in the gist I posted
> (https://gist.github.com/1036200), where |super| is essenti
On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
> There is no infinite recursion hazard in the semantics that Axel
> suggested, ...
Yes, I acknowledged that, but went on to repeat that an extra implicit
parameter is too costly (as opposed to a new internal property of functions).
> I don't thin
Le 22/06/2011 10:14, Tom Van Cutsem a écrit :
It just occurred to me that the security issues you describe re. fixed
properties & membranes may not be as bad as we first thought they were.
Because of the recursive wrapping of the membrane code, all of the
get/set/value attributes of fixed p
> From: Sean Eagan
> Date: June 22, 2011 15:48:18 GMT+02:00
>
> There is no infinite recursion hazard in the semantics that Axel
> suggested, and that I used in the gist I posted
> (https://gist.github.com/1036200), where |super| is essentially the
> "the [[Prototype]] internal property of the ob
On Wed, Jun 22, 2011 at 4:28 AM, Allen Wirfs-Brock
wrote:
>
> On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
>
>> One thing I'm not sure about: whether Object.defineMethod should mutate
>> C.prototype.foo's internal property, or make a new function object with a
>> different 'super' binding.
>
There is no infinite recursion hazard in the semantics that Axel
suggested, and that I used in the gist I posted
(https://gist.github.com/1036200), where |super| is essentially the
"the [[Prototype]] internal property of the object on which the method
or accessor getter or setter was found" except
On Jun 22, 2011, at 2:28 AM, Allen Wirfs-Brock wrote:
> On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
>
>> One thing I'm not sure about: whether Object.defineMethod should mutate
>> C.prototype.foo's internal property, or make a new function object with a
>> different 'super' binding.
>
> I
On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
> One thing I'm not sure about: whether Object.defineMethod should mutate
> C.prototype.foo's internal property, or make a new function object with a
> different 'super' binding.
I'm still thinking about this but I'm leaning towards specifying t
It just occurred to me that the security issues you describe re. fixed
properties & membranes may not be as bad as we first thought they were.
Because of the recursive wrapping of the membrane code, all of the
get/set/value attributes of fixed properties will contain wrappers
themselves. So, afte
29 matches
Mail list logo
