On Jul 24, 2010, at 12:27 PM, Brendan Eich wrote:
> On Jul 24, 2010, at 11:00 AM, Alex Russell wrote:
>
>> On Jul 24, 2010, at 9:21 AM, Kevin Curtis wrote:
>>
>>> Should the proposed shorter form # desugar to function or a const function:
>>> http://wiki.ecmascript.org/doku.php?id=strawman:const_functions
>>
>> Regular, plain-old function. No funky return semantics (ala some of the
>> closure proposals), no extra qualifiers. If you want 'em, you can pay for
>> 'em. The common problem "#" attempts to address is the huge verbosity of
>> "function", nothing more.
>
> That's not what the proposal from you and arv says :-/:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
>
> The completion value of the statements in the braced body of a # function is
> the return value.
I take the point, but again, that's to shorten things up, not to change
semantics where you would have otherwise added a "return".
My apologies for being imprecise.
>>> I dislike the verbosity of function - though I can't help feeling #
>>> could be used for other ends.
>>>
>>> let dict = #{"hello": 4, "world":5}; // it's a hash/dict not an object
>>
>> So a new dictonary/map type is interesting, but it's unclear that we really
>> need anything like that until/unless we turn off the "delete" operator.
>
> Why wouldn't you ever delete from a dictionary?
Oh, you would, but if you have a new dictionary type, you can turn of "delete"
in regular objects and provide a new method on the dict to handle that
internally.
> The real motivator for dictionaries is to avoid Object.prototype pollution of
> the dict's "in" (not "own") property namespace.
Which sound the like the long way around just providing a form of the iterator
that list only the hasOwnProperty items.
>>> let arr = #[4,4,5] // typed array - Numbers only - contiguous memory block?
>>
>> How about we start with the long form for things that are currently uncommon
>> and shorten them when they become painfully long to use?
>
> Good in general if you can iterate quickly enough. If we can cut to the
> chase, even better given the cycle times among browsers and Ecma editions.
...which can go down if we can get the cycle times for browser versions down.
We're building a language predicated on browser resource/network behavior
constraints and we succeed/fail by browser adoption. Given that browsers are
moving faster, I suspect we'll get another shot at shortening obviously-painful
and hard-to-use Harmony features sooner rather than later.
Regards
> I see Kevin's point, too: use # for "hashes" and other object initialiser
> extensions, use something more lambda-looking for function.
>
> /be
--
Alex Russell
[email protected]
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
