On Jun 23, 2011, at 4:54 AM, Axel Rauschmayer wrote:
>> How about this? You have a bunch of local variables in various functions
>> referencing different objects. But by some obscure yet legal means you use
>> one such reference to mutate the prototype object they share in common, so
>> all the
Adding := for a rare and usually wrong operation is not going to happen.
Let's please focus on real problems, especially when proposing new syntax.
/be
On Jun 23, 2011, at 4:56 AM, Axel Rauschmayer wrote:
> There are indeed a few ways around this:
> Naming the prototype, using an array with a s
Here is a code snippet:
var p = {};
(function(){
var a;
Object.defineProperty(p, 'a', {get:function(){return a;},
set:function(v){a = v;}});
})();
var o1 = Object.create(p);
var o2 = Object.create(p);
o1.a = 1;
console.log(o1.a, o2.a); // 1 1
o2.a = 37;
console.log(o1.a, o2.a); // 37
There are indeed a few ways around this:
Naming the prototype, using an array with a single element, etc.
On Jun 23, 2011, at 13:19 , David Bruant wrote:
> Hi,
>
> In a the provided example, you assign a value. Can't you just use a
> getter/setter pair on the prototype chain? It sounds like it
> How about this? You have a bunch of local variables in various functions
> referencing different objects. But by some obscure yet legal means you use
> one such reference to mutate the prototype object they share in common, so
> all the others appear to be mutated too.
>
> This is not inheren
I guess my argument goes like this:
- If the prototype of an instance loosely corresponds to a class, why shouldn’t
we have class variables/class state?
- If the location for reading data is abstracted over, why isn’t the location
for writing data?
On Jun 23, 2011, at 12:29 , Allen Wirfs-Brock w
Hi,
In a the provided example, you assign a value. Can't you just use a
getter/setter pair on the prototype chain? It sounds like it would solve
your use case (without the syntax sugar). On ES5 - 8.12.5 step 4 & 5,
the prototype chain is climbed to look up for an accessor and if there
is a se
On Jun 21, 2011, at 9:50 PM, Axel Rauschmayer wrote:
> That sounds like the opposite argument you are making with regard to the
> hypothetical |here|:
>
>> BTW I do not agree we can or should try to reserve 'here' or expose the
>> method's "home object" -- that breaks abstractions built using
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
> 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 21, 2011, at 1:50 PM, Axel Rauschmayer wrote:
> That sounds like the opposite argument you are making with regard to the
> hypothetical |here|:
>
>> BTW I do not agree we can or should try to reserve 'here' or expose the
>> method's "home object" -- that breaks abstractions built using p
That sounds like the opposite argument you are making with regard to the
hypothetical |here|:
> BTW I do not agree we can or should try to reserve 'here' or expose the
> method's "home object" -- that breaks abstractions built using prototypes.
> 'super' does not, because it always goes to the
On Jun 21, 2011, at 8:24 AM, Axel Rauschmayer wrote:
> As a loose analog to the prototype-chain-traversing getPropertyDescriptor(),
> I would still like to have something that allows one to easily *change*
> properties higher up the prototype chain (e.g. to use a prototype to share
> state).
S
As a loose analog to the prototype-chain-traversing getPropertyDescriptor(), I
would still like to have something that allows one to easily *change*
properties higher up the prototype chain (e.g. to use a prototype to share
state).
Maybe it would be enough to just have Object.getDefiningObject(
14 matches
Mail list logo