Attribute defaults for Object.defineProperty
On Aug 20, 2008, at 11:00 AM, Allen Wirfs-Brock wrote:
The default values for [[Writable]], [[Enumerable]], and
[[Flexible]] are all true as currently specified in Table 3 of
Section 8.6.1.
Hi Allen, could you remind me and a few others who were wondering
yesterday (sorry I don't remember -- it's in minutes, somewhere) why
[[Deletable]] was not chosen instead of [[Flexible]]? Thanks.
Deletable would match the other new names more closely in inverting
the sense of the ES1-3 attributes, avoiding Dont- prefixes which lead
to double-negative statements and the fuzzy meaning and marketing
connotations ("Agile!" ;-) of "flexible".
These defaults apply no matter how a property is created (by an
object literal, implicitly by assignment, by defineProperty and
friends). The defaults exactly match the default settings of the
corresponding ES3 attributes so there is no semantic change for the
property creation forms that already exist in ES3.
Special forms like var and function bind properties that are
DontDelete unless in eval code. Is this what Mark is getting at?
2008/8/20 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>:
[snip]
Finally, as I believe we have casually discussed, I can imagine that for ES-harmony we decide we want to introduce the concept of "method" properties.
What is a "method" property and how does it differ from a function-valued property?
[snip]
Peter
On Wed, Aug 20, 2008 at 11:00 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:
I'd like to resolve this fairly quickly so we can try to finalize the relevant parts of the 3.1 specification.
Let's use these issues as the agenda for tomorrow morning's phone call.
From: Brendan Eich [mailto:brendan at mozilla.org] Sent: Wednesday, August 20, 2008 11:25 AM [snip]
Hi Allen, could you remind me and a few others who were wondering yesterday (sorry I don't remember -- it's in minutes, somewhere) why [[Deletable]] was not chosen instead of [[Flexible]]? Thanks.
The reason for not using "deletable" was originally explained in the message below. I believe that at one of the phone meetings after Oslo we briefly discussed changing it back to "dynamic" or possibly something else but the consensus was to stick with "flexible".
If the word "flexible" is under debate, I think "redefinable" may be more specific.
And speaking of meta words, the function name Object.freeze() is a bit fuzzy. I think Object.lock() would suggest more strongly what it does.
Ingvar
writable: can be written to enumerable: can be enumerated flexible: can be flexed?
how about configurable?
Or arguably "reconfigurable".
We've had several discussions of most of these alternatives and so the consensus has been to stick with "flexible". We'll talk about it again today, but I wouldn't be surprised if the outcome is the same.
At the risk of beating a dead horse too much, based on the info you
provided it sounds like the "flexible" attribute isn't really an
attribute of the property, but an attribute of the attributes. Sort
that out appropriately in the APIs and the terminology may flow more
easily.
What about Fixed: neither its existence nor its type may be changed?
Although I'd prefer to control Deletable separately from Fixed,
because I'd love to see a delete added to get and set for properties.
Michael Haufe [mailto:TNO at TheNewObjective.com] said:
My suggestions:
[[IsMod]] "Is capable of being Modified"
Doesn't follow the "able" convention we established for attributes
[[Amendable]]
Possible confusion with [[Writable]]
[[Adaptable]]
Plausible, but when last considered [[Flexible]] won out over it. The common meaning of "configurable" seems a bit closer to the actual semantics than the common meaning of "adaptable"
[[Alter]] "Alterable"
Possible confusion with [[Writable]]
Jeff Watkins <Watkins at apple.com> said:
What about Fixed: neither its existence nor its type may be changed?
We've already consider "Fixed". Its common meaning and phonics are close enough to "freeze" (which is a term we are using for a related purpose) that we believe people would find the two terms confusing.
Although I'd prefer to control Deletable separately from Fixed,
Using a single state to control deletability, attribute mutability, and property transformation/replacement is a compromise. There may be some situations where somebody would really like to control these separately but it is probably a pretty limited use case. Individual attributes to control each of these types of transformations make the language and its implementation more complex. It might also make it more difficult to upgrade existing implementation to 3.1. As it is, we assume that most implementations can just repurpose their dontDelete bit (if they have one)
because I'd love to see a delete added to get and set for properties.
Don't quite understand what you are asking for here?
On 22 Aug, 2008, at 8:04 AM, Allen Wirfs-Brock wrote:
Jeff Watkins <Watkins at apple.com> said:
because I'd love to see a delete added to get and set for properties.
Don't quite understand what you are asking for here?
I can already define a getter and a setter for properties, I'd like to
be able to specify a deleter. Using the syntax proposed the other day
(which I really like):
var o= {
get foo: function()
{
// ...
},
set foo: function(newFoo)
{
// ...
},
delete foo: function()
{
// ...
}
};
I can think of a couple situations where this would be nice,
specifically around creating proxies for other objects. The only
drawback is that 'foo' in o always returns true.
Allen Wirfs-Brock wrote:
Michael Haufe [mailto:TNO at TheNewObjective.com] said:
Although I'd prefer to control Deletable separately from Fixed,
Using a single state to control deletability, attribute mutability, and property transformation/replacement is a compromise. There may be some situations where somebody would really like to control these separately but it is probably a pretty limited use case.
If you can set attribute mutability, then you can set the Delete attribute.
If you can set the Delete attribute, then you can delete the property (and its current attributes).
If you can delete the property, then you can recreate it with different attributes.
So, there is neither a security nor an expressiveness argument for making any distinction between these rights. An argument for separating them would have to be based on convenience (but it seems less convenient, not more), or on preventing inadvertent, non-malicious changes, or possibly on efficiency (but these operations are probably not common enough for that to be significant).
[[canMod]]
[[elastic]]
[[mutable]] <-- C++ has similar
[[pliant]]
On Aug 22, 2008, at 11:53 AM, David-Sarah Hopwood wrote:
Allen Wirfs-Brock wrote:
Michael Haufe [mailto:TNO at TheNewObjective.com] said:
Although I'd prefer to control Deletable separately from Fixed,
Using a single state to control deletability, attribute
mutability, and property transformation/replacement is a compromise. There may be
some situations where somebody would really like to control these
separately but it is probably a pretty limited use case.If you can set attribute mutability, then you can set the Delete
attribute.If you can set the Delete attribute, then you can delete the property (and its current attributes).
If you can delete the property, then you can recreate it with
different attributes.So, there is neither a security nor an expressiveness argument for
making any distinction between these rights. An argument for separating them would have to be based on convenience (but it seems less
convenient, not more), or on preventing inadvertent, non-malicious changes, or
possibly on efficiency (but these operations are probably not common enough for that to be significant).
Agreed on all points. The prototype-based language Wheat started with
what looked like Unix owner/group/other permission bits, but the
nonsense or dangerous combinations were eliminated (if my memory
serves). We should not even flirt with this kind of false orthogonality.
That's why DontDelete was not a bad name in its day. Even in ES1 or
the prior JavaScript and JScript implementations had something like
it (SpiderMonkey's name is "permanent").
It's not that "configurable" is bad, even if overlong. It is less
concrete in terms of what is controlled and why. Concrete names are
generally better.
No "CanMod", though -- I was flashing back to 6BIT charsets on DEC 36- bit processors ;-).
On Aug 21, 2008, at 9:55 AM, Allen Wirfs-Brock wrote:
Or arguably "reconfigurable".
On Thu, Aug 21, 2008 at 8:34 AM, Neil Mix <nmix at pandora.com> wrote:
At the risk of beating a dead horse too much, based on the info you provided it sounds like the "flexible" attribute isn't really an attribute of the property, but an attribute of the attributes.
(posting order restored)
I'm not sure if that's what it is or not. It seems that the documentation is very unclear and that is the source of the confusion.
The 3.1 draft defines [[Flexible]] as a property attribute:-
| [[Flexible]] boolean If true, attempts to delete the | property or change its attributes will succeed. Otherwise, | the property is said to be sealed. See the description of the | delete operator in section 11.4.1, and the reflective Object | methods .
That definition of [[Flexible]] seems to imply:
- true - property can be deleted using - delete - operator.
- false - property is sealed. What is sealed?
The closest I can come to defining "sealed" is Object.isSealed:-.
| 15.2.3.12 Object.isSealed ( O ) | When the isSealed function is called with argument O, | the following steps are taken: | 1. If Type(O) is not Object throw a TypeError exception. | 2. For each named own data property P of O, | a. Call the [[GetOwnProperty]] method of O with P. | b. If the [[Flexible]] field of Result(2a) is true, then return false. | 3. If the internal [[Extensible]] property of O is false, then return | true. | 4. Otherwise, return false. | The length property of the Object.isSealed function is 1.
Back to the definition of [[Flexible]]
- true - property can be deleted using - delete - operator.
- false - property is sealed. What is sealed?
So if the property is [[Flexible]], then the properties [[value]] must be an object which cannot be modified. What? I'm confused. :-(
What is [[Flexible]]? Is it an object modifier/attribute or a property attribute? If it's an object modifier, then [[Mutable]] is a better name. Otherwise, [[Deletable]] is a better name. It is unclear.
[[Mutable]] A mutable object can be modified with new properties and new values of existing non-final properties, after it is created.
An immutable object could be described as having no members whose values are changeable (const/final), with the additional rule that no properties could be added or deleted. An enum would be an example of an immutable object.
[[Deletable]] - the opposite of [[DontDelete]].
Allen, Pratap, can you clarify what this is?
Thanks,
Garrett
Sort that out appropriately in the APIs and the terminology may flow more easily.
We've had several discussions of most of these alternatives and so the consensus has been to stick with "flexible". We'll talk about it again today, but I wouldn't be surprised if the outcome is the same.
Allen
[snip]
On Sat, Aug 23, 2008 at 8:07 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
On Aug 21, 2008, at 9:55 AM, Allen Wirfs-Brock wrote:
Or arguably "reconfigurable".
On Thu, Aug 21, 2008 at 8:34 AM, Neil Mix <nmix at pandora.com> wrote: [snip]
The closest I can come to defining "sealed" is Object.isSealed:-.
| 15.2.3.12 Object.isSealed ( O ) | When the isSealed function is called with argument O, | the following steps are taken: | 1. If Type(O) is not Object throw a TypeError exception. | 2. For each named own data property P of O, | a. Call the [[GetOwnProperty]] method of O with P. | b. If the [[Flexible]] field of Result(2a) is true, then return false. | 3. If the internal [[Extensible]] property of O is false, then return | true. | 4. Otherwise, return false. | The length property of the Object.isSealed function is 1.
Back to the definition of [[Flexible]]
- true - property can be deleted using - delete - operator.
- false - property is sealed. What is sealed?
So if the property is [[Flexible]], then the properties [[value]] must be an object which cannot be modified. What? I'm confused. :-(
correction, I meant to write:- if [[Flexible]] is false, then the property's [[value]] must be an object which cannot be modified...
(that is what I interpreted from the spec). Allen, Pratap: Please elucidate.
What is [[Flexible]]? Is it an object modifier/attribute or a property
[snip]
Garrett
[snip]
Garrett Smith wrote:
It seems that the documentation is very unclear and that is the source of the confusion.
The 3.1 draft defines [[Flexible]] as a property attribute:-
| [[Flexible]] boolean If true, attempts to delete the | property or change its attributes will succeed. Otherwise, | the property is said to be sealed. See the description of the | delete operator in section 11.4.1, and the reflective Object | methods .
That definition of [[Flexible]] seems to imply:
- true - property can be deleted using - delete - operator.
- false - property is sealed. What is sealed?
You missed a very important part: "or change its attributes".
[[Flexible]] affects what you can do with a property and its attributes. It will feel more concrete if you change the word order:
,------- | [[Flexible]] boolean If true, attempts to change the attributes | of the property, or to delete the property, will succeed. `-------
Ignore "sealed", that word adds confusion. [[Flexible]] is not about an object as a whole.
There's a more informative description on page 9 of the PDF document that is linked to here: esdiscuss/2008-July/006664 Quoting from there, the following text talks about what this attribute affects:
,------- | In ES3 the possible basic state transitions of a property are | to create the property, to change the value of the property, | and to delete the property. The ES3 ReadOnly and DontDelete | property attributes regulate the ability make the latter two | transitions. With the addition of getter/setter properties | and reified property attributes, there are additional possible | property state transitions such as replacing a getter or setter | function, changing an attribute of a property, changing a data | property into a getter/setter property, and changing a getter/setter | property into a data property. `-------
I hope this helps.
On Sun, Aug 24, 2008 at 11:07 AM, Ingvar von Schoultz <ingvar-v-s at comhem.se> wrote:
Garrett Smith wrote:
,------- | [[Flexible]] boolean If true, attempts to change the attributes | of the property, or to delete the property, will succeed. `-------
Ignore "sealed", that word adds confusion. [[Flexible]] is not about an object as a whole.
There's a more informative description on page 9 of the PDF document that is linked to here: esdiscuss/2008-July/006664 Quoting from there, the following text talks about what this attribute affects:
,------- | In ES3 the possible basic state transitions of a property are | to create the property, to change the value of the property, | and to delete the property. The ES3 ReadOnly and DontDelete | property attributes regulate the ability make the latter two | transitions. With the addition of getter/setter properties | and reified property attributes, there are additional possible | property state transitions such as replacing a getter or setter | function, changing an attribute of a property, changing a data | property into a getter/setter property, and changing a getter/setter | property into a data property. `-------
I hope this helps.
Yes, it cleared up my confusion.
Thank you.
Garrett
Mark S. Miller wrote in: Look Ma, no "this"
The default values for [[Writable]], [[Enumerable]], and [[Flexible]] are all true as currently specified in Table 3 of Section 8.6.1. These defaults apply no matter how a property is created (by an object literal, implicitly by assignment, by defineProperty and friends). The defaults exactly match the default settings of the corresponding ES3 attributes so there is no semantic change for the property creation forms that already exist in ES3.
For consistency, I would think, that the default attribute values when a property is defined using defineProperty should remain the same as the default for other property definition forms. Making it different just increases the complexity of the language.
I don't really see why the current defaults should be a problem because whatever attributes you want "class members" to have you can achieve by explicitly specify the attribute value in the descriptors. Besides, such class definitions will ultimate get sugared.
Finally, as I believe we have casually discussed, I can imagine that for ES-harmony we decide we want to introduce the concept of "method" properties. If we do they could have different attributes and different defaults.
I'd like to resolve this fairly quickly so we can try to finalize the relevant parts of the 3.1 specification.