Re: Native base64 utility methods
On 5 May 2014, at 20:22, Andrea Giammarchi andrea.giammar...@gmail.com wrote: @mathias didn't mean to change atob and btoa rather add two extra methods such encode/decode for strings (could land without problems in the String.prototype, IMO) with less silly names whatever definition of silly we have ^_^ Agreed. Moving `TextEncoder`/`TextDecoder` to ES would be nice (but it requires `ArrayBuffer` / `Uint8Array`). http://encoding.spec.whatwg.org/#api ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the
keys of `source` objects. This helps avoid the method gotchas faced by
developers previously with things like `Object.prototype.writable = true`
and `Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description(bottom
of section)
Bear in mind that these options are not necessarily own properties so, if
inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all
options explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even
though false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make
sense to make things like ToPropertyDescriptor use [[HasOwnProperty]] too.
I think it would be a win for consistency and dev use.
Thoughts?
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
I agree with you that this would be a much better design, but it would break
backwards compatibility with ES5, no?
Minor nitpick: I guess you mean to say that ToPropertyDescriptor should use the
abstract operation HasOwnProperty, not [[HasOwnProperty]]...
Fred
From: John-David Dalton
john.david.dal...@gmail.commailto:john.david.dal...@gmail.com
Date: Thursday, May 8, 2014 at 1:25 PM
To: es-discuss Steen es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the keys
of `source` objects. This helps avoid the method gotchas faced by developers
previously with things like `Object.prototype.writable = true` and
`Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description
(bottom of section)
Bear in mind that these options are not necessarily own properties so, if
inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all options
explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even though
false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make sense to
make things like ToPropertyDescriptor use [[HasOwnProperty]] too. I think it
would be a win for consistency and dev use.
Thoughts?
- JDD
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail (including
the original message in your reply) and then delete and discard all copies of
the e-mail.
Thank you.
-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptor can return just about anything
Allen, Mark and I discussed the [[Origin]] issue and came to the following consensus: We remove [[Origin]] and revert to the originally specified behavior ( http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec) where the descriptor returned by the proxy is coerced into a fresh, normalized, completed, ordinary descriptor object. This ensures complete backward-compatibility with the ES5 behavior (i.e. Object.getOwnPropertyDescriptor will always return a fresh, complete data or accessor descriptor), and doesn't allow a proxy to play tricks with descriptor objects. Allen's remaining concern is that this disallows proxies (or new exotic objects) from inventing new types of descriptors, next to data and accessor descriptors. Due to backwards-compat. constraints, we're basically stuck with these two types of property descriptors forever. The originally specified Proxy behavior also included copying any non-standard attributes provided by the proxy onto the fresh descriptor object. However, if we're serious about keeping Object.getOwnPropertyDescriptor backwards-compatible with existing ES5 code, we may be better off by not augmenting descriptor objects with non-standard attributes, even if this is unlikely to break existing code. As Jason mentioned, if proxies want to introduce new per-property attributes, they can provide other means of getting at that meta-data rather than abusing the standard reflection API. So, the current proposal is to spec [[GetOwnProperty]] for Proxies such that the descriptor returned by the trap is coerced into a fresh, normalized, complete descriptor object, without copying custom attributes. Relevant bug seems to already have been filed by Andre: https://bugs.ecmascript.org/show_bug.cgi?id=2382 Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
I agree with you that this would be a much better design, but it would
break backwards compatibility with ES5, no?
There have been other changes to the spec that are technically back-compat
breaking like Object.keys('x') no longer throwing an error.
I think this change would benefit developers as the case seems to be devs
getting bitten by the current behavior.
Minor nitpick: I guess you mean to say that ToPropertyDescriptor should
use the abstract operation HasOwnProperty, not [[HasOwnProperty]]
Sure, I'll switch to ES6y terms. Yes, I mean the abstract operation
HasOwnProperty.
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
that does not save you from errors when `Object.prototype.get =
function(){}` since `writable` and `get/set` cannot coexist in a descriptor
... a safe approach is to create `var descriptor = Object.create(null);`
and then set its `value` later on before assignment.
I remember early discussion with Allen and Brendan about this, the solution
was a hybrid [[HasNonObjectProperty]] check so that everything inherited
except `Object.prototype` was considered ... although:
1. we have two kind of descriptors, accessors and value descriptors. I
don't know who would create classes in order to inherit just a couple of
propeties ... like `new WritableButNotConfigurable(value)` ? Has anyone
ever seen a piece of code like that?
2. accordingly to point one, descriptors should rather change into
`null` objects ASAP and stop this descriptor minefield I am pretty sure
nobody expect or desire to work like that
Changing that part of the specs iw say easier than defining a new
[[HasNonObjectProperty]] pattern, IMO
My 2 cents
On Thu, May 8, 2014 at 1:25 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the
keys of `source` objects. This helps avoid the method gotchas faced by
developers previously with things like `Object.prototype.writable = true`
and `Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description(bottom
of section)
Bear in mind that these options are not necessarily own properties so, if
inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all
options explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even
though false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make
sense to make things like ToPropertyDescriptor use [[HasOwnProperty]] too.
I think it would be a win for consistency and dev use.
Thoughts?
- JDD
___
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: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
iw=say ... is way
On Thu, May 8, 2014 at 2:38 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
that does not save you from errors when `Object.prototype.get =
function(){}` since `writable` and `get/set` cannot coexist in a descriptor
... a safe approach is to create `var descriptor = Object.create(null);`
and then set its `value` later on before assignment.
I remember early discussion with Allen and Brendan about this, the
solution was a hybrid [[HasNonObjectProperty]] check so that everything
inherited except `Object.prototype` was considered ... although:
1. we have two kind of descriptors, accessors and value descriptors. I
don't know who would create classes in order to inherit just a couple of
propeties ... like `new WritableButNotConfigurable(value)` ? Has anyone
ever seen a piece of code like that?
2. accordingly to point one, descriptors should rather change into
`null` objects ASAP and stop this descriptor minefield I am pretty sure
nobody expect or desire to work like that
Changing that part of the specs iw say easier than defining a new
[[HasNonObjectProperty]] pattern, IMO
My 2 cents
On Thu, May 8, 2014 at 1:25 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the
keys of `source` objects. This helps avoid the method gotchas faced by
developers previously with things like `Object.prototype.writable = true`
and `Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description(bottom
of section)
Bear in mind that these options are not necessarily own properties so,
if inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all
options explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even
though false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make
sense to make things like ToPropertyDescriptor use [[HasOwnProperty]] too.
I think it would be a win for consistency and dev use.
Thoughts?
- JDD
___
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: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
OK, hasOwnProperty per descriptor would work too ... probably even easier
as spec change than having all null objects
+1 to that
On Thu, May 8, 2014 at 2:35 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
I agree with you that this would be a much better design, but it would
break backwards compatibility with ES5, no?
There have been other changes to the spec that are technically back-compat
breaking like Object.keys('x') no longer throwing an error.
I think this change would benefit developers as the case seems to be devs
getting bitten by the current behavior.
Minor nitpick: I guess you mean to say that ToPropertyDescriptor should
use the abstract operation HasOwnProperty, not [[HasOwnProperty]]
Sure, I'll switch to ES6y terms. Yes, I mean the abstract operation
HasOwnProperty.
- JDD
___
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: Object.getOwnPropertyDescriptor can return just about anything
On Thu, May 8, 2014 at 5:23 PM, Tom Van Cutsem tomvc...@gmail.com wrote: Allen, Mark and I discussed the [[Origin]] issue and came to the following consensus: We remove [[Origin]] and revert to the originally specified behavior ( http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec) where the descriptor returned by the proxy is coerced into a fresh, normalized, completed, ordinary descriptor object. This ensures complete backward-compatibility with the ES5 behavior (i.e. Object.getOwnPropertyDescriptor will always return a fresh, complete data or accessor descriptor), and doesn't allow a proxy to play tricks with descriptor objects. Allen's remaining concern is that this disallows proxies (or new exotic objects) from inventing new types of descriptors, next to data and accessor descriptors. Due to backwards-compat. constraints, we're basically stuck with these two types of property descriptors forever. The originally specified Proxy behavior also included copying any non-standard attributes provided by the proxy onto the fresh descriptor object. However, if we're serious about keeping Object.getOwnPropertyDescriptor backwards-compatible with existing ES5 code, we may be better off by not augmenting descriptor objects with non-standard attributes, even if this is unlikely to break existing code. As Jason mentioned, if proxies want to introduce new per-property attributes, they can provide other means of getting at that meta-data rather than abusing the standard reflection API. So, the current proposal is to spec [[GetOwnProperty]] for Proxies such that the descriptor returned by the trap is coerced into a fresh, normalized, complete descriptor object, without copying custom attributes. Relevant bug seems to already have been filed by Andre: https://bugs.ecmascript.org/show_bug.cgi?id=2382 Forgive me if this has already been discussed elsewhere, but the Notes section of [[GetOwnProperty]](P) lists several invariants that are similar in nature to the following (which I've just made up): - A property cannot be reported as configurable, if it does not exists as an own property of the target object or if it exists as a non-configurable own property of the target object. - A property cannot be reported as writable, if it does not exists as an own property of the target object or if it exists as a non-writable own property of the target object. - A property cannot be reported as enumerable, if it does not exists as an own property of the target object or if it exists as a non-enumerable own property of the target object. Then descriptors would allow user-invented descriptor properties, while still upholding the target's integrity. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
On May 8, 2014, at 1:25 PM, John-David Dalton wrote:
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the keys
of `source` objects. This helps avoid the method gotchas faced by developers
previously with things like `Object.prototype.writable = true` and
`Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description
(bottom of section)
Bear in mind that these options are not necessarily own properties so, if
inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all options
explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even
though false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make sense
to make things like ToPropertyDescriptor use [[HasOwnProperty]] too. I think
it would be a win for consistency and dev use.
Thoughts?
some prior discussions on this topic (or related):
http://esdiscuss.org/topic/nuking-misleading-properties-in-object-getownpropertydescriptor
http://www.esdiscuss.org/topic/object-prototype-get-bye-bye-object-defineproperty
http://esdiscuss.org/topic/property-descriptors-as-es6-maps
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
Thanks for the discussion links, Allen. I'm I reading it right that there was no concrete resolution to the issue? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
On May 8, 2014, at 4:05 PM, John-David Dalton wrote: Thanks for the discussion links, Allen. I'm I reading it right that there was no concrete resolution to the issue? Right, nothing concrete came out of it so won't happen for ES6. Post-ES6 is always possible. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
Is Post-ES6 up for discussion? Should I create a spec bug for tracking this? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
On Fri, May 9, 2014 at 1:44 AM, John-David Dalton john.david.dal...@gmail.com wrote: Should I create a spec bug for tracking this? Please do. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
