just my 0.02,
setter, considered inline, are more like:
```javascript
return doSomethingWith(name, value), value;
```
than
```javascript
var result = doSomethingWith(name, value);
return result === undefined ? value : result;
```
also because returning `undefined`, as setting `undefined`, would be a
valid and totally ambiguous operation.
In first case at least, it's never ambiguous, you know that value you are
passing to set is the one you'll have back, no matter what, unless Error
occurs.
A trick to "return" something else during a `set` can be throwing
`{another:'value'}` indeed and catch it later on ... but it's a very weird
pattern I would personally not recommend.
Cheers
On Tue, Feb 18, 2014 at 10:07 AM, David Bruant <bruan...@gmail.com> wrote:
> Le 18/02/2014 18:55, Erik Arvidsson a écrit :
>
> https://bugs.ecmascript.org/show_bug.cgi?id=2511
>>
>> We now have our first setter in the spec. However, it is speced to return
>> the value itself. This is pretty inconsistent with WebIDL and the common
>> practice to not include a return value in setters in object literals.
>>
> In practice, the returned value of setting is the value on the rhs of the
> =.
>
> var o = {set b(v){return 12;}} // this return statement is useless
>
> console.log(o.a = 13); // 13
> console.log(o.b = 14); // 14
>
> It might be useful to return a different value on setting. I think Haxe
> does it.
> Note that it would require to rework the set trap of proxies a bit
> (currently, it returns a boolean indicating success or failure).
>
>
> Can we get the spec changed to return undefined?
>>
> That would be the most coherent option with the language as it is today.
>
> David
> _______________________________________________
> 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
