User:Jorend/Properties

Here is the taxonomy of properties I propose:

Data properties - These are reflected as data properties via Object.getOwnPropertyDescriptor and are shadowed rather than assigned when [[Set]] via the prototype chain. There are three kinds:

• Plain data property - Slotful, no getter or setter. (We should give up the internal jargon "default getter" and just say "no getter".)
• Method - The existing JSPROP_METHOD optimization. The illusion can't stand up to intense scrutiny, so if you do anything too weird to it, the method barrier is tripped and it becomes a plain data property. It can't be non-configurable for this reason.
• JSPropertyOp data property - Like the .length property of arrays. For correctness, Object.defineProperty will have to be updated to understand these; it must indeed "see through" the property ops somehow in order to behave correctly per ES5. I think this means that the getter must be effect-free and maybe infallible.

Accessor properties - These are reflected as accessor properties, and when [[Set]] via the prototype chain, the setter is called. There are two kinds:

• Plain accessor property - With callable JSObjects as the getter and setter, just like properties with JSPROP_GETTER/SETTER today.
• JSPropertyOp accessor property - For DOM accessor properties implemented via quickstubs. I foresee this being like a method in that any introspection causes us to create the get and set function objects and "collapse" this into an ordinary accessor property (sort of like the method read barrier). mrbkap has partly implemented this in quickstubs, actually.

All other combinations would be forbidden, and we would enforce that with assertions, or better, by making JSObject::addProperty and putProperty private and offering typed methods (addDataProperty, addMethodProperty, ...) instead.