getter and setter inheritance

Kris Zyp kris at
Sun May 11 16:40:04 PDT 2008

When an object A is defined that inherits from it's prototype object B that 
has a getter and setter defined for "foo", and object A wants to inherit the 
behavior of B except for a slight modification to the getter behavior, it 
could be advantageous if the setter could still be inherited without having 
to redefine it on object A. If the developer wants to make property "foo" 
read-only, this can still easily be done by creating a setter that throws an 
exception (or does nothing).
That being said, I would still favor the approach of treating 
getters/setters as a full slot, where inheritance doesn't go past 
half-definitions because that is behavior that is currently used on the web 

Also, the idea of making setters without getters illegal is interesting. 
However, while they may be rare, I think setters without getters has use 
cases. This seems like unnecessary arbitrary restriction to dissallow 
setters without getters. Furthermore, this is not the behavior of current 
browsers, there is no precedent in JavaScript implementations for preventing 
this combination. Is there other reasons for this restriction that I am not 
aware of?


----- Original Message ----- 
From: "Mark S. Miller" <erights at>
To: "Kris Zyp" <kris at>
Cc: <es3.x-discuss at>; "es4-discuss Discuss" 
<es4-discuss at>
Sent: Sunday, May 11, 2008 10:23 AM
Subject: Re: getter and setter inheritance

> 2008/5/9 Kris Zyp <kris at>:
>> A question of how inheritance/delegation should work with getters and
>> setters was raised in a recent discussion.
> Hi Kris,
> The way I've been thinking of getters and setters is as if there are
> two kinds of properties:
> * A data property is defined by its current value, and whether the
> value is writable. If the value is not writable, the property is
> considered read-only.
> * A procedural property is defined by a getter function and an
> optional setter function. If there is no setter function, the property
> is considered read-only.
> For both kinds of properties, a property is further defined by its
> property name, whether the property is enumerable, and whether the
> property's definition is redefinable. (Where redefinable implies
> deletable.) This would be reflected (so to speak) concretely in the
> results of Object.getProperties and Object.getProperty, and in the
> argument of Object.defineProperties.
>  Object.getProperty(x, 'foo') => {value: 3, writable: false,
> enumerable: false, redefinable: false}
>  Object.getProperty(x, 'bar') => {getter: function(){return 3;},
> enumerable: false, redefinable: false}
> in which case and are behaviorally identical for
> non-reflective clients.
>> If there is an object A whose
>> prototype is object B, and object A defines a getter for property foo, 
>> and
>> object B defines a setter for property foo, and we write a value to 
>> should the setter defined on object B be called?
> I think it should be illegal to define a setter without defining a
> getter. A procedural property should either have a getter or have a
> getter and a setter.
> Assuming B defines a getter and a setter for foo, and A defines a
> getter for foo, the answer should be no. A's own foo is a read-only
> procedural property that fully masks B's foo.
>> If A didn't define any
>> property on A, the setter would be inherited from B and would be called 
>> when
>> was modified.
> Yes.
>> However, with the getter defined on A, should the
>> inheritance stop at A, because there is a slot defined, or should it
>> continue along the prototype chain because there was no setter defined 
>> for
>> that property (nor plain value)?
> Stop at A. s/slot/property
>> The question also applies when the getter
>> and setter are reversed. When a property is accessed and there is a 
>> setter
>> defined, but no getter,
> That case should be rejected as illegal.
>> should we continue to down the prototype chain to
>> find a getter or a plain value, or stop and return undefined? AFAICT, ES4
>> doesn't explicitly define which is the correct behavior. Firefox follows 
>> the
>> former behavior:
>> B={set foo(v){foo = v},
>>     get bar(){return "bar value"}}
> should be rejected as illegal.
>> A={get foo(){return "foo value"},
>>     set bar(v){bar = v},
>>     __proto__:B}
> should be rejected as illegal.
> -- 
>    Cheers,
>    --MarkM

More information about the Es4-discuss mailing list