right, that's nice, just wonder if at that time to pass an object will be
slightly ambiguous
function fn({a: a = {}, b: b = true}) { ... }
fn(genericObject) will fail as first argument so that
fn({a: genericObject}) will be necessary
If these things are optimized on engine levels then "who cares", same as I
would not care about
StructType({x: 1, y: 1})
if engines are smart enough to understand the purpose of that unreferenced
object is to initialize a static type
In that case 90% of my worries about typed stuff are gone so, good stuff.
Regards,
Andrea
On Sun, Sep 18, 2011 at 6:26 PM, Brendan Eich <bren...@mozilla.com> wrote:
> On Sep 18, 2011, at 12:09 PM, Andrea Giammarchi wrote:
>
> I know it's the same, for this reason I said it was "shimmable"
>
> New syntax would be fine as long as minifiers won't break everything so ...
> as long as minifiers are compatible, but this is an extra story I guess,
> also it's not fundamental it's just nicer addiction since many libs are
> using single object as function argument to obtain similar behavior
>
> fn({a: 1, b: 2})
>
> and back to the "too many objects created due lack of defaults/named
> arguments" trap ...
>
>
> For this style of parameter-object passing, ES6 destructuring helps. The fn
> function would be declared:
>
> function fn({a, b}) {...}
>
> This is already supported in SpiderMonkey in Firefox, but ES6 adds a
> feature wanted for defaulting missing properties:
>
> function fn({a = 1, b = 2}) {...}
>
> (long-hand is function fn({a: a = 1, b: b = 2}) {...}).
>
> That way you can call fn({a: 3}) or fn({b: 4}) and have the missing
> property filled in with its default value.
>
> Optimizing implementations can avoid creating the object passed as an
> actual parameter by specializing when inlining or caching.
>
> This parameter-object style is already popular. With destructuring +
> parameter default values, it tends to take away the motivation for keyword
> parameters of the kind you sought.
>
>
> Never mind, this is not for this thread.
>
>
> It's ok, we can change the subject if necessary to fork a sub-thread.
>
> /be
>
>
>
> Best Regards,
> Andrea Giammarchi
>
>
> On Sun, Sep 18, 2011 at 3:14 PM, Brendan Eich <bren...@mozilla.com> wrote:
>
>> On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
>>
>> On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich <bren...@mozilla.com>wrote:
>>
>>>
>>> The point is that you don't *have* to pass a fresh object literal to each
>>> constructor call.
>>>
>>> /be
>>>
>>>
>> I know Brendan, my point is that I can predict devs will do every time
>> .... we'll see
>>
>> Thanks for other reply, I thought named arguments where proposed tho ...
>> any chance we can discuss this somehow ? ( not here )
>>
>>
>> Can't use =, that is just the assignment operator, so
>>
>> foo(a = 1, b = 2)
>>
>> is the same as
>>
>> (a = 1, b = 2, foo(a, b))
>>
>> We'd need some new operator or punctuator, e.g.
>>
>> foo(a: 1, b: 2)
>>
>> or
>>
>> foo(a => 1, b => 2) // clashes with arrow function syntax
>>
>> Anyway, this only helps for the "top ply" of the object/array tree
>> containing values to store as binary data. You'd still have object and array
>> literals starting one ply down.
>>
>> /be
>>
>>
>>
>>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
