Re: An Introduction to JS-Ctypes
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 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 wrote:
>
>> On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
>>
>> On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich 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
Re: Class Syntax Proposal, Complete With Arguments For and Examples.
On Sat, Sep 17, 2011 at 10:36 PM, Jonathan Dumaine < jonathan.duma...@dumstruck.com> wrote: > Hello Mark, > > I think mistake is a harsh word. > My apologies if it came across as harsh. I did not intend harshness, quite that opposite. That's why I mentioned that the committee almost made the same mistake -- to let you know you were in good company. [...] > > Perhaps you could direct me to the discussion the committee has already had > on this matter so I could better form my arguments? > It was brief and verbal. It may have been captured in the meeting notes. But I don't think there's much more to say on this particular matter than what I've said. I don't think much more was said at the time. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
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 wrote:
> On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
>
>> On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich 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
Re: Class Syntax Proposal, Complete With Arguments For and Examples.
On Sun, Sep 18, 2011 at 1:36 AM, Jonathan Dumaine wrote: > You could go > all the way and make classes a very strict subset of the language: throw an > error if the user tries to set a property of a class instance that has > already been declared private [...] > I would personally prefer the prior route: sacrifice some of javascript's > dynamic attributes in favor of better abstraction and encapsulation > capabilities. But one problem here is exactly related to abstraction and encapsulation: the class's implementation can't add a new private property without risking breaking of existing clients: if they were using the newly-claimed name as an "expando" property's name, then the changes to the "encapsulated and abstracted" internal representation will cause them to error out. Mike ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
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 ...
Never mind, this is not for this thread.
Best Regards,
Andrea Giammarchi
On Sun, Sep 18, 2011 at 3:14 PM, Brendan Eich wrote:
> On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
>
> On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich 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
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote: > On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich 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 Then they'll optimize. Developers know how to make code fast, just by A-B testing and folklore, if not by profiling. The problem for JS is when performance is unpredictable, i.e., when optimization faults happen. This isn't analogous. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote: > On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich 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
Re: An Introduction to JS-Ctypes
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich 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 ) Cheers ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
