Re: Array.prototype.contains

[Allen Wirfs-Brock]

On Nov 1, 2012, at 11:04 AM, Joshua Bell wrote:

> Bump.
> 
> I don't think Array.prototype.contains ever materialized on the "proposals" 
> page, and hasn't shown up in an ES6 draft.
> 
> Officially out for ES6, stuck in the queue, or dropped on the floor?

Probably dropped on the floor, unless somebody can find something about it in 
meeting notes.

It looks to me from scanning just this thread that it was an idea that was 
floated here with generally positive responses, but had some unresolved issues, 
and nobody ever signed on as champion to write an actual proposal.  

Allen







> 
> On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron  wrote:
> Allen, thank you for the clarification there
> 
> 
> Rick
> 
> 
> On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock  wrote:
> 
>> 
>> On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:
>> 
>>> 
>>> 
>>> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson  
>>> wrote:
>>> DOM4 added a new interface called DOMStringList for the sole reason
>>> that Array does not have contains. Before this the return type was an
>>> Array of Strings so we could use indexOf, map, forEach etc. Now that
>>> it is using a non Array we lost all of that.
>>> 
>>> Wouldn't the return type (or [[Class]]) still be restricted from using 
>>> "Array"? 
>>> 
>>> From 8.6.2
>>> 
>>> The value of the [[Class]] internal property is defined by this 
>>> specification for every kind of built-in object. The value of the [[Class]] 
>>> internal property of a host object may be any String value except one of 
>>> "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON", 
>>> "Math", "Number", "Object", "RegExp", and "String". 
>>> 
>>> 
>>> So it can't be an "Array" by name, right?
>>> 
>> 
>> It can be, as long as it really is a ES array.  "host object" doesn't mean 
>> any object created by the host.  It means new kinds of objects created by 
>> the host that implement primitive behaviors (generally internal methods) 
>> differently from what is specified by the ES spec.  
>> 
>> So, from the ES perspective, no problem.  When I originally asked the 
>> question I was thinking more about from the Web IDL perspective.  Does Web 
>> IDL require things (for example throwing if extra arguments are passed) that 
>> ES Arrays do not do.
>> 
>> 
>> Allen
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMap and primitive keys

[Allen Wirfs-Brock]

On Nov 1, 2012, at 10:40 PM, Brendan Eich wrote:

> On file?

already fixed in my draft.

> 
> Nathan, thanks for catching this!
> 
> /be
> 
> Allen Wirfs-Brock wrote:
>> copy/paste bug!!
>> 
>> Allen
>> 
>> On Nov 1, 2012, at 9:05 AM, Nathan Wall wrote:
>> 
>>> Looking at the recent draft, I noticed that the WeakMap methods accept 
>>> primitive keys, converting them to objects, and acting like an object was 
>>> passed in. This differs from the current behavior of Chrome and Firefox, 
>>> which both throw if key is not an object. It seems, as the current draft 
>>> reads, passing in a primitive will fail silently, since weakmap.set(3, 
>>> 'some value'); weakmap.get(3); will be undefined. Is this a bug in the 
>>> draft or was it decided not to throw in these situations (or am I 
>>> misunderstanding the draft)?
>>> 
>>> 
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org 
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMap and primitive keys

[Brendan Eich]

On file?

Nathan, thanks for catching this!

/be

Allen Wirfs-Brock wrote:

copy/paste bug!!

Allen

On Nov 1, 2012, at 9:05 AM, Nathan Wall wrote:

Looking at the recent draft, I noticed that the WeakMap methods 
accept primitive keys, converting them to objects, and acting like an 
object was passed in. This differs from the current behavior of 
Chrome and Firefox, which both throw if key is not an object. It 
seems, as the current draft reads, passing in a primitive will fail 
silently, since weakmap.set(3, 'some value'); weakmap.get(3); will be 
undefined. Is this a bug in the draft or was it decided not to throw 
in these situations (or am I misunderstanding the draft)?



___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMap and primitive keys

[Allen Wirfs-Brock]

copy/paste bug!!

Allen

On Nov 1, 2012, at 9:05 AM, Nathan Wall wrote:

> Looking at the recent draft, I noticed that the WeakMap methods accept 
> primitive keys, converting them to objects, and acting like an object was 
> passed in. This differs from the current behavior of Chrome and Firefox, 
> which both throw if key is not an object. It seems, as the current draft 
> reads, passing in a primitive will fail silently, since weakmap.set(3, 'some 
> value'); weakmap.get(3); will be undefined. Is this a bug in the draft or was 
> it decided not to throw in these situations (or am I misunderstanding the 
> draft)?
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property descriptors as ES6 Maps

[Axel Rauschmayer]

(Assuming that I understand the issue.)

The "object to map" refactoring matters whenever you don't know the keys in 
advance. If you do, as is the case with property descriptors, objects are fine. 
Then they are more like records than like maps.

Axel

[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com

On 01.11.2012, at 10:37, Tom Van Cutsem  wrote:

> Hi,
> 
> David, I think I see where you are going: property descriptors are basically 
> "bags" of key/value properties, and maps are a more direct representation of 
> this concept than objects.
> 
> On the other hand, as so carefully explained by Allen, there currently isn't 
> really an issue with the mapping between property descriptors and objects: at 
> all the boundary points, we make sure to properly convert descriptors into 
> well-behaved objects and vice versa.
> 
> As you point out yourself, making the change from objects to maps implies a 
> bunch of backwards compat. issues. My position is that doing the object->map 
> refactoring at this stage would entail a lot of work for very little gain.
> 
> Finally, remember that property descriptors-as-objects really leverage the 
> object literal notation (i.e. I can create a property descriptor by just 
> writing "{value:42,writable:true}". I don't think there is a corresponding 
> sweet syntax for literal maps? In any case, Object.defineProperty will need 
> to continue accepting such literal objects as its third argument, so why not 
> keep the story simple and not widen the type to object | map.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

WeakMap and primitive keys

[Nathan Wall]

Looking at the recent draft, I noticed that the WeakMap methods accept 
primitive keys, converting them to objects, and acting like an object was 
passed in. This differs from the current behavior of Chrome and Firefox, which 
both throw if key is not an object. It seems, as the current draft reads, 
passing in a primitive will fail silently, since weakmap.set(3, 'some value'); 
weakmap.get(3); will be undefined. Is this a bug in the draft or was it decided 
not to throw in these situations (or am I misunderstanding the draft)?

  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Descriptors as script compatible representation (was: Property descriptors as ES6 Maps)

[Allen Wirfs-Brock]

On Nov 1, 2012, at 6:03 AM, David Bruant wrote:

> Le 31/10/2012 19:03, Allen Wirfs-Brock a écrit :
>> Let me summarize what I think is your concern.
>> 
>> In ES5, property descriptor records are a specification device that is used 
>> to transport information about object properties between factored components 
>> of the ES specification. The same information can be expressed as an ES 
>> object that is produced/consumed by Object.getOwnPropertyDescriptor and 
>> Object.defineProperty.  These are raising/lowering operations that move 
>> information from the specification/implication level to the reflective ES 
>> language level.  One advantage of this layering is that the conversion 
>> to/from an actual object takes place once, at a well defined point in the 
>> execution sequence and any side-effects of object access occur only at that 
>> point.  Once the information is represented as an internal "record" we know 
>> that all internal consistency preconditions are satisfied and that no 
>> side-effects can be associated with access to such records.
> The part about precondition is particularly interesting and I agree it
> should be kept. However, it's possible to define ECMAScript contructs
> that enforce such pre-conditions. My point is that even for the spec,
> it's possible to define PropertyDescriptors by using ECMAScript
> constructs, without necessarily creating a new spec-only type.

It's possible, but not necessarily wise.  We current have a fairly complete 
stratification of the implementation/core semantics layer of ES from the 
reflection layer.  This is a good thing, and something that we should be trying 
to preserve as we introduce proxies.  Layer crossings should be minimized.  
Using higher level level entities to represent lower layer abstractions would 
be going in the opposite direction. 
> 
>> You concern seems to be that a proxy traps that deal with descriptor objects 
>>  have no such guarantees and in particular strange things might happen if a 
>> descriptor object is itself a proxy.
> My original concern was that the defineProperty and
> getOwnPropertyDescriptor traps I/O were interacting directly with
> PropertyDescriptor algorithms, but after re-reading the proxy spec page
> more carefully, I realized it is not the case. However, not being the
> case has a cost:
> 
> The proxies_spec page [1] redefines some ES5 15.2.3.* built-ins.
> Core of the current Object.getOwnPropertyDescriptor is :
> 3) Let desc be the result of calling the [[GetOwnProperty]] internal
> method of O with argument name.
> 4) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).
> 
> Core of the proposed Object.getOwnPropertyDescriptor is :
> 3) If O is a proxy
>Return the result of calling TrapGetOwnProperty(O, name)
> 4) Let desc be the result of calling the [[GetOwnProperty]] internal
> method of O with argument name.
> 5) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).

The above isn't how this will be expressed in the final spec.  Instead we will 
have 

3) Let desc be the result of calling the [[GetOwnProperty]] internal
method of O with argument name.
4) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).

And all Proxy objects will have a [[GetOwnProperty]] internal methods that 
looks something like:

1) Let O be the object upon which this internal method was invoked.
2) Let desc be the result of calling TrapGetOwnProperty(O,name)
3) Return ToPropertyDescriptor(desc)

(I left out details of exception handling) 

> 
> If [[GetOwnProperty]] returned the same type of thing than
> TrapGetOwnProperty (which returns an object), the spec 15.2.3.3
> Object.getOwnPropertyDescriptor could remain the same.

But introduces a mutable object (regular a regular object or map doesn't 
matter) into the lower layer.

> Also, I have the
> feeling that there is duplicated logic between TrapGetOwnProperty and
> FromPropertyDescriptor or unnecessary back and forth conversions between
> internal PropertyDescriptor and objects.

Unnecessary duplication will be minimized in the final spec.  As will 
unnecessary conversions.  However some of these conversions are necessary to 
stratify the reflection layer.  The are also necessary to prevent property 
descriptor objects from being unintentionally shared or used as a transport 
mechanism through the implementation layer.  


> 
> Currently, TrapGetOwnProperty returns an object, but when there is an
> actual trap, it goes through:
> * NormalizeAndCompletePropertyDescriptor(Object) -> Object (step 6)
> * ToCompletePropertyDescriptor(Object) -> PropertyDescriptor (step 3 of
> NormalizeAndCompletePropertyDescriptor)
> * FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of
> NormalizeAndCompletePropertyDescriptor)

Possibly details to cleanup, I need to look deeper.  The bottom line, all 
specification algorithms such as Object.getOwnPropertyDescriptor must be 
expressed in terms of essential, trapable internal

Re: Array.prototype.contains

[Joshua Bell]

Bump.

I don't think Array.prototype.contains ever materialized on the "proposals"
page, and hasn't shown up in an ES6 draft.

Officially out for ES6, stuck in the queue, or dropped on the floor?

On Fri, Feb 24, 2012 at 4:40 PM, Rick Waldron wrote:

> Allen, thank you for the clarification there
>
>
> Rick
>
>
> On Feb 24, 2012, at 7:19 PM, Allen Wirfs-Brock 
> wrote:
>
>
> On Feb 24, 2012, at 11:09 AM, Rick Waldron wrote:
>
>
>
> On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson 
> wrote:
>
>> DOM4 added a new interface called DOMStringList for the sole reason
>> that Array does not have contains. Before this the return type was an
>> Array of Strings so we could use indexOf, map, forEach etc. Now that
>> it is using a non Array we lost all of that.
>>
>
> Wouldn't the return type (or [[Class]]) still be restricted from using
> "Array"?
>
> From 8.6.2
>
> The value of the [[Class]] internal property is defined by this
> specification for every kind of built-in object. The value of the [[Class]]
> internal property of a host object may be any String value except one of
> "Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON",
> "Math", "Number", "Object", "RegExp", and "String".
>
>
> So it can't be an "Array" by name, right?
>
>
> It can be, as long as it really is a ES array.  "host object" doesn't mean
> any object created by the host.  It means new kinds of objects created by
> the host that implement primitive behaviors (generally internal methods)
> differently from what is specified by the ES spec.
>
> So, from the ES perspective, no problem.  When I originally asked the
> question I was thinking more about from the Web IDL perspective.  Does Web
> IDL require things (for example throwing if extra arguments are passed)
> that ES Arrays do not do.
>
>
> Allen
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Erik Arvidsson]

On Thu, Nov 1, 2012 at 4:32 PM, Andrea Giammarchi
 wrote:
> Just wondering if this is actually meant/expected, I am talking about the
> example here:
>
> http://wiki.ecmascript.org/doku.php?id=harmony:observe#example

I'm not sure I understand your point. The example is not normative and
it doesn't say anything about timing.

> and the fact it should show something in console while in my opinion that
> should show nothing since the Object.unobserve is called in the same "tick"

The delivery of the mutation records is async, not the calls to
Object.observe or Object.unobserve.

> Then I read the algo and I wonder if this won't create many problems, i.e.
> enabling a new way to leak objects through observers that should not be
> called once the object is not observed anymore, specially because there's no
> way to understand if the object is observed or not, isn't it?

Leak in what sense? Memory, security?

If someone has access to a non frozen object they can observe changes
to its data properties. This is not a new capability, it can be done
today by polling or rewriting them as accessors.

> Thanks for any sort of clarification.

I'm not sure that answer your questions?

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Synchronous Object.observe but Asynchronous Object.unobserve ?

[Andrea Giammarchi]

Just wondering if this is actually meant/expected, I am talking about the
example here:

http://wiki.ecmascript.org/doku.php?id=harmony:observe#example

and the fact it should show something in console while in my opinion that
should show nothing since the Object.unobserve is called in the same "tick"

Then I read the algo and I wonder if this won't create many problems, i.e.
enabling a new way to leak objects through observers that should not be
called once the object is not observed anymore, specially because there's
no way to understand if the object is observed or not, isn't it?

Thanks for any sort of clarification.

br
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property descriptors as ES6 Maps

[Brandon Benvie]

Another argument against using maps is it can actually be pretty useful to
use the features that prototypal inheritance and the object model provides.

function Descriptor(configurable, enumerable){
  this.configurable = configurable;
  this.enumerable = enumerable;
}

Descriptor.prototype = {
  configurable: undefined,
  enumerable: undefined,
  inerit: function inerit(){
return Object.create(this);
  }
};

function DataDescriptor(value, writable, enumerable, configurable){
  this.value = value;
  this.writable = writable;
  this.enumerable = enumerable;
  this.configurable = configurable;
}
DataDescriptor.prototype = new Descriptor
DataDescriptor.prototype.value = undefined;
DataDescriptor.prototype.writable = undefined;

function AccessorDescriptor(get, set, enumerable, configurable){
  this.get = get;
  this.set = set;
  this.enumerable = enumerable;
  this.configurable = configurable;
}
AccessorDescriptor.prototype = new Descriptor;
AccessorDescriptor.prototype.get = undefined;
AccessorDescriptor.prototype.set = undefined;

function Value(value){
  this.value = value;
}
Value.prototype = new DataDescriptor(undefined, true, true, true);

function HiddenValue(value){
  this.value = value;
}
Value.prototype = new DataDescriptor(undefined, true, false, true);

function Accessor(get, set){
  this.get = get;
  this.set = set;
}
Accessor.prototype = new AccessorDescriptor(undefined, undefined, true,
true);

function Getter(get){
  this.get = get;
}
Getter.prototype = new Accessor;

function Setter(set){
  this.set = set;
}
Setter.prototype = new Accessor;
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property descriptors as ES6 Maps

[David Bruant]

Le 01/11/2012 10:37, Tom Van Cutsem a écrit :
> On the other hand, as so carefully explained by Allen, there currently
> isn't really an issue with the mapping between property descriptors
> and objects: at all the boundary points, we make sure to properly
> convert descriptors into well-behaved objects and vice versa.
Indeed.
What do you think of the idea of exposing objects that would be
well-behaved as property descriptor by construction? These objects can
be used both internally and at trap boundaries.
It wouldn't be compulsory to preserve backward compat, but just more
efficient.

The name I've used in my answer to Allen is awful, but it can obviously
be changed :-) (maybe PropDesc or PropertyDescriptor?)

> As you point out yourself, making the change from objects to maps
> implies a bunch of backwards compat. issues. My position is that doing
> the object->map refactoring at this stage would entail a lot of work
> for very little gain.
I agree.

> Finally, remember that property descriptors-as-objects really leverage
> the object literal notation (i.e. I can create a property descriptor
> by just writing "{value:42,writable:true}". I don't think there is a
> corresponding sweet syntax for literal maps?
I don't think maps are a good idea any longer, but for this point, I
think the following has been suggested:
Map({value:42, writable:true})
(If it hasn't yet, it sounds like a fanstastic idea to initialize ES6 maps!)

The constructor I have proposed could have an equivalent initialization
syntax.
Object.defineProperty({}, 'a', PropDesc({value:42, writable:true}))

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Property Descriptors as script compatible representation (was: Property descriptors as ES6 Maps)

[David Bruant]

Le 31/10/2012 19:03, Allen Wirfs-Brock a écrit :
> Let me summarize what I think is your concern.
>
> In ES5, property descriptor records are a specification device that is used 
> to transport information about object properties between factored components 
> of the ES specification. The same information can be expressed as an ES 
> object that is produced/consumed by Object.getOwnPropertyDescriptor and 
> Object.defineProperty.  These are raising/lowering operations that move 
> information from the specification/implication level to the reflective ES 
> language level.  One advantage of this layering is that the conversion 
> to/from an actual object takes place once, at a well defined point in the 
> execution sequence and any side-effects of object access occur only at that 
> point.  Once the information is represented as an internal "record" we know 
> that all internal consistency preconditions are satisfied and that no 
> side-effects can be associated with access to such records.
The part about precondition is particularly interesting and I agree it
should be kept. However, it's possible to define ECMAScript contructs
that enforce such pre-conditions. My point is that even for the spec,
it's possible to define PropertyDescriptors by using ECMAScript
constructs, without necessarily creating a new spec-only type.

> You concern seems to be that a proxy traps that deal with descriptor objects  
> have no such guarantees and in particular strange things might happen if a 
> descriptor object is itself a proxy.
My original concern was that the defineProperty and
getOwnPropertyDescriptor traps I/O were interacting directly with
PropertyDescriptor algorithms, but after re-reading the proxy spec page
more carefully, I realized it is not the case. However, not being the
case has a cost:

The proxies_spec page [1] redefines some ES5 15.2.3.* built-ins.
Core of the current Object.getOwnPropertyDescriptor is :
3) Let desc be the result of calling the [[GetOwnProperty]] internal
method of O with argument name.
4) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).

Core of the proposed Object.getOwnPropertyDescriptor is :
3) If O is a proxy
Return the result of calling TrapGetOwnProperty(O, name)
4) Let desc be the result of calling the [[GetOwnProperty]] internal
method of O with argument name.
5) Return the result of calling FromPropertyDescriptor(desc) (8.10.4).

If [[GetOwnProperty]] returned the same type of thing than
TrapGetOwnProperty (which returns an object), the spec 15.2.3.3
Object.getOwnPropertyDescriptor could remain the same. Also, I have the
feeling that there is duplicated logic between TrapGetOwnProperty and
FromPropertyDescriptor or unnecessary back and forth conversions between
internal PropertyDescriptor and objects.

Currently, TrapGetOwnProperty returns an object, but when there is an
actual trap, it goes through:
* NormalizeAndCompletePropertyDescriptor(Object) -> Object (step 6)
* ToCompletePropertyDescriptor(Object) -> PropertyDescriptor (step 3 of
NormalizeAndCompletePropertyDescriptor)
* FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of
NormalizeAndCompletePropertyDescriptor)

We might as well get rid of the spec-only PropertyDescriptor, define an
equivalently pre-condition/invariant enforcing ES5 construct and
manipulate that both internally and in trap boundaries.


> The getOwnPropertyDescriptor trap is a lowering operation. (...)
>
> The defineProperty trap is a raising operation. (...)
>
> The other possible concern would be that a trap might directly use 
> Object.getOwnPropertyDescriptor on a proxy object and that this might provide 
> a bogus descriptor.  But it can't.  (...)
I agree with what you wrote here. Basically, the thing that prevent
potentially harmful descriptors-as-proxies to being harmful is that from
getOwnPropertyDescriptor and to defineProperty traps, the "essence" of
the descriptor is copied to a fresh object created internally.

> so, I just don't see any basis for your concern.  Perhaps, you could 
> elaborate on the nature of the problem as you perceive it.
Let's try to ASCII-art it. Here are the paths that property descriptors
take. Arrows represent a internal type conversion and/or descriptor
completion/normalization
# Object.defineProperty on regular object:
ES Object (in user script) --> PropertyDescriptor (and stored as such)

# Object.defineProperty on proxies (as I understand its current
specification):
ES Object --> PropertyDescriptor --> ES Object (for trap argument) -->
PropertyDescriptor
The last arrow is not compulsory, but we can decently assume that for
most cases, the defineProperty trap will forward the operation to the target

# What I'm suggesting is to do the following in both cases:
ES Object --> ESUsablePropDesc (used for proxy trap arguments)


I think I was wrong in suggesting using raw ES6 Maps (and I think I
understand that's what Andreas meant regarding heterogeneous types). The
idea of ESUsable

Re: Property descriptors as ES6 Maps

[Tom Van Cutsem]

Hi,

David, I think I see where you are going: property descriptors are
basically "bags" of key/value properties, and maps are a more direct
representation of this concept than objects.

On the other hand, as so carefully explained by Allen, there currently
isn't really an issue with the mapping between property descriptors and
objects: at all the boundary points, we make sure to properly convert
descriptors into well-behaved objects and vice versa.

As you point out yourself, making the change from objects to maps implies a
bunch of backwards compat. issues. My position is that doing the
object->map refactoring at this stage would entail a lot of work for very
little gain.

Finally, remember that property descriptors-as-objects really leverage the
object literal notation (i.e. I can create a property descriptor by just
writing "{value:42,writable:true}". I don't think there is a corresponding
sweet syntax for literal maps? In any case, Object.defineProperty will need
to continue accepting such literal objects as its third argument, so why
not keep the story simple and not widen the type to object | map.

Cheers,
Tom

2012/10/31 Allen Wirfs-Brock 

> Let me summarize what I think is your concern.
>
> In ES5, property descriptor records are a specification device that is
> used to transport information about object properties between factored
> components of the ES specification. The same information can be expressed
> as an ES object that is produced/consumed by
> Object.getOwnPropertyDescriptor and Object.defineProperty.  These are
> raising/lowering operations that move information from the
> specification/implication level to the reflective ES language level.  One
> advantage of this layering is that the conversion to/from an actual object
> takes place once, at a well defined point in the execution sequence and any
> side-effects of object access occur only at that point.  Once the
> information is represented as an internal "record" we know that all
> internal consistency preconditions are satisfied and that no side-effects
> can be associated with access to such records.
>
> You concern seems to be that a proxy traps that deal with descriptor
> objects  have no such guarantees and in particular strange things might
> happen if a descriptor object is itself a proxy.
>
> I don't think any of this is actually a problem.  First there are only a
> few traps that directly deal with descriptor objects.
>
> The getOwnPropertyDescriptor trap is a lowering operation.  It is called
> by a proxy's [[GetOwnProperty]]  internal method implementation. The
> internal method expects to get back a property descriptor object which it
> must then lower (via the ToPropertyDescriptor abstract operation) into a
> descriptor record.  ToPropertyDescriptor can throw if the descriptor object
> being lowered is malformed or if it  misbehaves (via accessor properties or
> by being a Proxy itself) but that is ok because throwing is part of the
> specified behavior of ToPropertyDescriptor and once we are past that we
> know we have a well-formed internal descriptor record that is not subject
> to tampering.   Keeping the original object around would infect the entire
> downstream use of the property descriptor with the possibility of
> side-effects.
>
> The defineProperty trap is a raising operation.  It is called by a Proxy's
>  [[DefineOwnProperty]] internal method and starts with an internal
> descriptor record.  The internal method converts the record to an object
> (via the FromPropertyDescriptor abstract operation) and passes that object
> to the trap.  Note that this is guaranteed to be a ordinary object (not a
> proxy) and that the properties that describe property attributes are
> guaranteed to be data properties.  So, defineProperty traps don't need to
> worry about getting passed a bogus property descriptor object as an
> argument.
>
> The other possible concern would be that a trap might directly use
> Object.getOwnPropertyDescriptor on a proxy object and that this might
> provide a bogus descriptor.  But it can't.  Object.getOwnPropertyDescriptor
>  may trigger a getOwnPropertyDescriptor trap but as described above this is
> a lowering operation that produces a well formed property descriptor record
> (or throws if it can not).  That lowered record is immediately raised via
> FromPropertyDescriptor, so we know that Object.getOwnPropertyDescriptor
> always returns an ordinary object that is a well formed, side-effect free
> property descriptor object.
>
> so, I just don't see any basis for your concern.  Perhaps, you could
> elaborate on the nature of the problem as you perceive it.
>
> Allen
>
>
>
>
>
>
>
> On Oct 31, 2012, at 2:40 AM, David Bruant wrote:
>
> > Hi,
> >
> > I've recently filed a spec bug [1] and given more thoughts about it that
> > goes beyond the suggested restructuring so I'm bringing it up here. This
> > posts ends up with an unresolved issue, but I hope a solution can be
> found.
> >
> > Let's tal