On 5/7/11, Faisal Vali wrote:
>> "Kyle Simpson"
>> Date: Sat, 7 May 2011 21:58:32 -0500
>> Subject: Re: arrow syntax unnecessary and the idea that "function" is too
>> long
>
>
>
>> With all due respect, Brendan's personal tastes on what kind of code he
>> likes to write is not enough.
>> It has
I wrote PHP full time for years. -> can get pretty aggravating. # is
50% shorter, and doesn't use the same fingers that type the (). ()->
is a lot of right-hand-dancing.
That being said, it does look pretty nice, and we're all just going to
set our editors to do that for us anyhow, right?
On S
> "Kyle Simpson"
> Date: Sat, 7 May 2011 21:58:32 -0500
> Subject: Re: arrow syntax unnecessary and the idea that "function" is too long
> With all due respect, Brendan's personal tastes on what kind of code he likes
> to write is not enough.
> It has to be something that is likely to find wid
On Sat, May 7, 2011 at 8:04 PM, Kyle Simpson wrote:
> Good, we're making progress. Previously I was not responding to your
>> original request, I was responding to your response to Crock's message.
>> Hence our confusion about premises. Thanks for making your's clearer. As for
>> your original re
Good, we're making progress. Previously I was not responding to your
original request, I was responding to your response to Crock's message.
Hence our confusion about premises. Thanks for making your's clearer. As
for your original request, now that I better understand what you're
looking for,
But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
they are definitely not a representative
It has been my experience that professional JavaScripters will cheer
*any* idea that shortens the spelling of "function" and "return" :)
Brendan has said that 8 characters for "function" is at least 6 too
many. I think it's probably at least 7 too many. But it'd be a shame
to remove the characte
On Sat, May 7, 2011 at 5:05 PM, Kyle Simpson wrote:
> My first reaction to this assertion is to say: "so?" It's a rather moot
>>> argument to suggest that code which can be altered before it's run isn't
>>> trustable... of course it isn't. [...] because any malicious script (if it's
>>> first on
David,
Thanks for those clarifying points, much appreciated.
>From an academic perspective, I'm also curious about the change from # to ->
To be honest, # always seemed weird to me, but I welcome a shortened syntax
regardless
Rick
-- Sent from my Palm Pre
On May 7, 2011 8:18 PM, Juan Ignac
In fact, isn't this the whole point of modules, and module scope? If
you evaluate a script inside a module scope, your global prototypes
are protected anyway. This is already kind of where JS is heading. I
saw your (Kyle) tweets last night about "module formats", and I sort
of agree, but we also ha
whoah! I didn't know that. Why doesn't that work with:
function o () {}; o.prototype=null; new o();
?
As for the current discussion, I should think that some way to
instantiate a new "clean" global object, and inject it into the
current scope would be somewhat more useful, as it would enable n
Since there's a call for developer feedback, I'll give mine.
Brendan once said "JS is a curly-brace language and it always will be". I
think the -> looks works very nice with a pythonic-like forced indentation
like Coffeescript has. However, I believe # looks better with curly braces,
so I'd keep
> But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
> they are definitely not a representative
My first reaction to this assertion is to say: "so?" It's a rather moot
argument to suggest that code which can be altered before it's run isn't
trustable... of course it isn't. [...] because any malicious script (if
it's first on the page) can completely hijack another part of the page?
Yup, I
Le 07/05/2011 20:44, Douglas Crockford a écrit :
> On 11:59 AM, Oliver Hunt wrote:
>>
>> It does annoy me that these were not made immutable. The safest way
>> to create an object is still either with an object literal or new
>> SomeFunction;
>>
>> I'm not convinced that Object.create added anyth
On Sat, May 7, 2011 at 1:17 PM, Kyle Simpson wrote:
> Again, a "smart library" can only do that if it's guaranteed to be the
>>> first code to run on the page. If not (which is usually the case), then all
>>> bets are off, unless the language offers some protections.
>>>
>>
>> All bets are probab
Based on what evidence are "we" concluding that the majority of the
javascript developers want -> syntax for functions? The fact that
coffeescript is the hot buzzword? Was there some developer-community wide
voting or poll that I missed? Or is it that a few vocal people on these
lists like it,
> Based on what evidence are "we" concluding that the majority of the
> javascript developers want -> syntax for functions? The fact that
> coffeescript is the hot buzzword? Was there some developer-community wide
> voting or poll that I missed? Or is it that a few vocal people on these lists
>
> JavaScript won't ever be known as a outstanding functional programming
> language until it has proper tail calls. This would give the language
> new capabilities it doesn't have now.
Proper tail calls are *already* in Harmony and totally orthogonal to the
question of new function syntax.
Dave
Consider this: w = (x)->y || z
That code is not obvious at all. Which of these would it be?
1: w = function (x) { return y } || z
2: w = function (x) { return y || z }
It seems to me that there must be some sort of delineation
around the function start and end.
But such delineation does n
On Sat, May 7, 2011 at 1:04 PM, Peter Michaux wrote:
> JavaScript won't ever be known as a outstanding functional programming
> language until it has proper tail calls. This would give the language
> new capabilities it doesn't have now.
http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail
On 5/7/11, Isaac Schlueter wrote:
[...]
Blocks in JS are useless, can't we just do away
> with them?
>
Blocks are required for many productions such as try/catch/finally.
Almost all existing code uses blocks to group statements together.
Blocks can't be removed.
--
Garrett
___
Again, a "smart library" can only do that if it's guaranteed to be the
first code to run on the page. If not (which is usually the case), then
all bets are off, unless the language offers some protections.
All bets are probably still off. The malicious code that's first can load
the latter vir
For what it's worth, I'm a *huge* fan of Ruby's {|-style blocks.
Also, it's worth noting that "do...done" seems to be a bit more
popular in Ruby programs that I've seen.
I'm not a fan of the fact that these blocks have different behavior
than "regular" functions and methods, but that's a qualm for
On Sat, May 7, 2011 at 11:54 AM, Kyle Simpson wrote:
> The malicious script could schedule patching newly loaded code
>> directly without even overwriting Object.prototype (eg. to reuse your
>> example, it could replace document.location.href occurences with a
>> string constant in the 'trustwort
The malicious script could schedule patching newly loaded code
directly without even overwriting Object.prototype (eg. to reuse your
example, it could replace document.location.href occurences with a
string constant in the 'trustworthy' function source directly).
Not if the code in question is i
On 11:59 AM, Oliver Hunt wrote:
It does annoy me that these were not made immutable. The safest way to create
an object is still either with an object literal or new SomeFunction;
I'm not convinced that Object.create added anything of value to the language,
and certainly wouldn't recommend
i
On Sun, May 8, 2011 at 00:35, Kyle Simpson wrote:
>> Doesn't Object.freeze(Object.prototype) provide exactly this behavior
>> already?
>
> It does (I suppose), if you're positive that your code is the first code to
> run on the page. I'm more talking about code out in the wild, where
> malicious/h
It's a well known fact that overwriting anything in Object.prototype
(like
Object.prototype.toString, for instance) is a very bad idea, because it
breaks for-in looping.
Properties 'properly' added/updated using Object.defineProperty
{enumerable: false} do not break for-in afaik.
I wasn't awa
On May 7, 2011, at 10:24 AM, Cedric Vivier wrote:
>> 2. Would it be possible for Object.prototype.* to be read-only for
>> ES-Harmony (or even just strict mode)?
>> 3. By read-only, I mean that changes to it would just silently be discarded.
>> Alternatively (especially for strict mode), warnings/
On Sat, May 7, 2011 at 23:44, Kyle Simpson wrote:
> It's a well known fact that overwriting anything in Object.prototype (like
> Object.prototype.toString, for instance) is a very bad idea, because it
> breaks for-in looping.
Properties 'properly' added/updated using Object.defineProperty
{enumer
On Sat, May 7, 2011 at 9:56 AM, Thaddee Tyl wrote:
> JavaScript is still seen as a badly object-oriented programming
> language by those who still think it is java with a weird syntax.
I think that concpetion has declined a lot as rich clients have forced
people to become better acquainted with
On Sat, May 7, 2011 at 6:31 PM, Peter Michaux wrote:
> On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl wrote:
>> I believe that David Bruant has a good point. We *need* a shorter syntax
>> because we advocate the use of map/reduce, etc., which require simple
>> anonymous functions.
>
> No. We don't "
I apologize if the question I'm about to ask has already been "dealt
with", but I just ran across a nasty instance of it, and wanted to just
ping the topic to see what the language guardians have to say about it.
It's a well known fact that overwriting anything in Object.prototype (like
Object
I apologize if the question I'm about to ask has already been "dealt with",
but I just ran across a nasty instance of it, and wanted to just ping the
topic to see what the language guardians have to say about it.
It's a well known fact that overwriting anything in Object.prototype (like
Object
On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl wrote:
> I believe that David Bruant has a good point. We *need* a shorter syntax
> because we advocate the use of map/reduce, etc., which require simple
> anonymous functions.
No. We don't "need" syntactic sugar. The current function syntax is
working
I believe that David Bruant has a good point. We *need* a shorter syntax
because we advocate the use of map/reduce, etc., which require simple
anonymous functions.
As to why we should choose # rather than coffescript's ->, there are two points:
- The # syntax is more readable. -> is perlish. It l
On Sat, May 7, 2011 at 6:04 AM, Sam Tobin-Hochstadt wrote:
> On Sat, May 7, 2011 at 2:22 AM, Peter Michaux wrote:
>>
>> I think that this is what compilers and projects like coffeescript are
>> for. In my opinion, JavaScript itself doesn't need this new syntax.
>>
>> I think improving JavaScript
Le 05/05/2011 20:38, Tom Van Cutsem a écrit :
> (...)
>
> Also, as you point out, full consistency across all traps is difficult
> to guarantee, so does it make sense to enforce consistency for some
> traps but not for others? The overall behavior of the proxy may still
> be inconsistent.
>
> I do
On Sat, May 7, 2011 at 2:22 AM, Peter Michaux wrote:
>
> I think that this is what compilers and projects like coffeescript are
> for. In my opinion, JavaScript itself doesn't need this new syntax.
>
> I think improving JavaScript as a compilation target is a good goal.
This argument comes up tim
Just to add my two cents, I would like to let you remember that the arrow
syntax should not be viewn as the only way to avoid the 'return' statement
and the brackets. "function(x) x*x;" does the trick too, whithout
introducing any new keyword. To those that think that the arrow syntax is
easier
On 07/05/2011, at 02:04, Peter Michaux wrote:
> (...)
>
> If the arrow syntax is only syntactic sugar for the existing function
> forms then I don't see how it achieves any of the goals he outlined.
> The only possible category is "be a better language" but the arrow
> syntax won't make JavaScript
42 matches
Mail list logo
