Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
It also made me think that perhaps Object.mixin might be a more
intuitive name for such a function.
This name is certainly more real-word-friendly.
Works well as an arrow function due to not needing to turn it into a block
body, although forEach and a comma would work too.
Object.mixin = (target, source) =
Object.keys(source).reduce((target, key) =
Object.defineProperty(target, key,
Object.getOwnPropertyDescriptor(source, key))
),
Allen Wirfs-Brock wrote:
3) I don't see any reason that it should be restricted to enumerable
properties. If the intend is to deprecate enumerable along with for-in
then we should be adding new functionality that is sensitive to the
state of the enumerable attribute.
Allen
Well, I had a
agreed, and actually one of the best case I've seen in a while for
Array#reduce.
Can I write this as it should be for those who'll read one day later on and
making it also static ?
mixin in Object || Object.defineProperty(Object, mixin, {
value: function mixin(target, source) {
return
Ah yes errors. It should probably have similar semantics to how
defineProperties works now...attempting each property and holding errors
until the end, no? Same for assign.
function mixin(target, source){
if (Type(target) !== 'Object') throw new TypeError (target must be an
object);
if
a single property from a mixin that cannot be defined could compromise
entirely the behavior so I would actually throw instantly then I believe no
try catch is even necessary there, correct?
On Wed, Dec 12, 2012 at 9:42 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
Ah yes errors. It
On Wed, Dec 12, 2012 at 9:42 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
Ah yes errors. It should probably have similar semantics to how
defineProperties works now...attempting each property and holding errors
until the end, no? Same for assign.
No, we want early errors and accurate
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we want this feature to land and not just spin around here.
jjb
As Object.mixin or as Object.define??
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
All the Object functions that operate on multiple properties are currently
specified using *pendingException* which reports the first thrown exception
after going through all the properties. defineProperties, freeze, etc.
___
es-discuss mailing list
Brandon Benvie wrote:
Works well as an arrow function due to not needing to turn it into a
block body, although forEach and a comma would work too.
Object.mixin = (target, source) =
Object.keys(source).reduce((target, key) =
Object.defineProperty(target, key,
On Wed, Dec 12, 2012 at 10:05 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we want this feature to land and not just spin around
here.
jjb
As Object.mixin or as Object.define??
Object.mixin
jjb
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object functions that operate on multiple properties are currently
specified using pendingException which reports the first thrown exception
after going through all the properties. defineProperties, freeze, etc.
In, ES6. This is
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object functions that operate on multiple properties are currently
specified using *pendingException* which reports the first thrown
exception after
Yeah, it makes sense. If a property throws then you're going to end up with
a partially completed action either way (unless the very first one fails in
the ES5 rules), so it's better to fail predictably. While the iteration
order of the keys is defined, in this case it's usually not useful for
In order to know what the end state will be for any given property, you
currently need to know whether every preceding property throws or not. With
the ES6 change, there's no interdependence between properties as to whether
they'll end up being visited or not.
On Wed, Dec 12, 2012 at 1:23 PM,
On Dec 11, 2012, at 10:42 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
3) I don't see any reason that it should be restricted to enumerable
properties. If the intend is to deprecate enumerable along with for-in
then we should be adding new functionality that is sensitive to the
A contrived example but it demonstrates the problem
Object.mixin({}, Proxy({ a: 5, b: 10, c: 20 }, {
getOwnPropertyDescriptor(target, key){
if (key === 'b' Math.random() * .5) {
throw 'halt';
}
return Reflect.getOwnPropertyDescriptor(target, key);
}
}));
In ES5 rules
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object functions that operate on multiple properties are currently
specified using
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:05 AM, Brandon Benvie wrote:
All the Object
On Dec 12, 2012, at 10:10 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:05 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we want this feature to land and not just spin around here.
jjb
As
I'd vote for replacing duplicate properties by default (as I tend to see
this as the common case). That being said, the mixin functions I use
tend to have an optional third argument that let's you change that
behavior, such as:
// regular
Object.mixin(receiver,supplier);
// safe
On Dec 12, 2012, at 10:52 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:18 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec
On Wed, Dec 12, 2012 at 11:20 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:52 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:23 AM, John J Barton wrote:
On Wed, Dec 12,
On Dec 12, 2012, at 11:40 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 11:20 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 10:52 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec
On Wed, Dec 12, 2012 at 11:57 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
How would throwing early versus throwing late make any different to you?
Because 1) late is a waste, the result is undefined anyway, 2) the exception
thrown is a lie, the operation did not die on the property
I think the latter should replace the previous as overwrite and would not
care much about same property name with only a getter VS only a setter. If
a developer wants both it can use mixin() to define the descriptor.
Back to Nicolas third parameter, true is not as powerful as a
function(target,
On Wed, Dec 12, 2012 at 11:13 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 12, 2012, at 10:10 AM, John J Barton wrote:
On Wed, Dec 12, 2012 at 10:05 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 12, 2012, at 9:50 AM, John J Barton wrote:
...
But most of all we
The spec says for the various Object functions that the properties are
iterated in list order. Doesn't this indicate the order is defined?
On Wed, Dec 12, 2012 at 4:57 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Wed, Dec 12, 2012 at 11:13 AM, Allen Wirfs-Brock
On Dec 12, 2012, at 2:27 PM, Brandon Benvie wrote:
The spec says for the various Object functions that the properties are
iterated in list order. Doesn't this indicate the order is defined?
Except that the List in question is created containing the names of each
enumerable own property of
On Dec 11, 2012, at 10:19 AM, Andrea Giammarchi wrote:
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use
all ES5 features for mixins too.
I totally agree as well.
Also, the Nicolas example is potentially disaster prone, not in that
specific form, but in the way a
Wholeheartedly agree with this. For library authoring it's a necessity, so
a define like function is always the first thing in any .js file I make.
The need for library authors is obvious but if I recall the conclusion was
that those authors would be able to handle it themselves and to push off on
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
I'm the past we discussed issues surrounding the semantic differences
between put and define and we've agreed to include Object.assign in
ES6. We have also discussed Object.define but have not yet made a decision
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences between
put and define and we've agreed to include Object.assign in ES6. We have
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use
all ES5 features for mixins too.
Also, the Nicolas example is potentially disaster prone, not in that
specific form, but in the way a getter with private scope access could be.
Imagine many objects using that specific
On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences
On Tue, Dec 11, 2012 at 1:12 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I'm the past we discussed issues surrounding the semantic differences
On Dec 11, 2012, at 10:19 AM, Mark S. Miller wrote:
On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Except,
1) It needs to iterate own keys, not just string valued property names so it
will pick up properties whose keys are symbols
2) It needs to rebind
On Tue, Dec 11, 2012 at 1:27 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
2) It needs to rebind super references
3) I don't see any reason that it should be restricted to enumerable
properties. If the intend is to deprecate enumerable along with for-in
then
we should be adding new
On Dec 11, 2012, at 10:19 AM, Andrea Giammarchi wrote:
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use all
ES5 features for mixins too.
Also, the Nicolas example is potentially disaster prone, not in that specific
form, but in the way a getter with private scope
what I think is a very valid use case for mixins based on ES5 features
var MixIt = Object.defineProperties({}, {
name: {
enumerable: true,
get: function () {
// notify or do stuff
return this._name;
},
set: function (_name) {
// notify or do stuff
40 matches
Mail list logo
