On 4/17/11, Wes Garland wrote:
> On 17 April 2011 20:09, Garrett Smith wrote:
>
>> Function.prototype.toString says "yes."
>>
>
> That's not a really valid evaluation IMO. At least in mozilla's case, the
> semi colon appears in this by virtue of the bytecode decompiler putting a
> semicolon at th
Implementation specific -- JSC Function.prototype.toString returns the exact
input string for the body of the function.
--Oliver
On Apr 17, 2011, at 5:09 PM, Garrett Smith wrote:
> On 4/17/11, Mikeal Rogers wrote:
>> do modern javascript implementations actually "insert" semicolons?
>>
> Func
An implementation _could_ add a mode (*shudder*) along the same lines as strict
mode:
"die in hell ASI, i hate you with the fiery passion of a thousand burning
suns.";
And then make it a syntax error whenever ASI would occur. I have considered
this in JSC (albeit with a slightly shorter opt in
On 17 April 2011 20:09, Garrett Smith wrote:
> Function.prototype.toString says "yes."
>
That's not a really valid evaluation IMO. At least in mozilla's case, the
semi colon appears in this by virtue of the bytecode decompiler putting a
semicolon at the end of every statement. The source-code-as
On 4/17/11, Mikeal Rogers wrote:
> do modern javascript implementations actually "insert" semicolons?
>
Function.prototype.toString says "yes."
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 4/17/11, Jason Orendorff wrote:
> On Sun, Apr 17, 2011 at 12:07 PM, Garrett Smith
> wrote:
>> On 4/17/11, Brendan Eich wrote:
>>> On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
>> [TLDR]
>>> ASI is not going to be removed. I don't know why you think it could be.
>>>
>> Why not? Iif develop
do modern _javascript_ implementations actually "insert" semicolons?
i would assume that the parser would simply adhere to a set of rules when parsing in to an AST and those rules would govern what ends a particular statement, one of those rules being a semicolon.
_
On 4/17/11, Allen Wirfs-Brock wrote:
>
> On Apr 17, 2011, at 12:33 PM, Mike Ratcliffe wrote:
>
>> ...
>>
>> Personally I would welcome some kind of option to disable ASI with open
>> arms. Garrett's strict mode warning idea makes sense to me but I am fairly
>> certain that not everybody would welc
On Sun, Apr 17, 2011 at 12:07 PM, Garrett Smith wrote:
> On 4/17/11, Brendan Eich wrote:
>> On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
> [TLDR]
>> ASI is not going to be removed. I don't know why you think it could be.
>>
> Why not? Iif developers would stop doing that then eventually, can
On 11:59 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2011, at 6:14 AM, Kyle Simpson wrote:
Many JSON serializer implementations escape the "/" character, including for instance PHP's
json_encode(). However, JavaScript's own JSON.stringify() does not. If you look at the grammar on
json.org, as I r
On Apr 17, 2011, at 12:33 PM, Mike Ratcliffe wrote:
> ...
>
> Personally I would welcome some kind of option to disable ASI with open arms.
> Garrett's strict mode warning idea makes sense to me but I am fairly certain
> that not everybody would welcome it.
> ~
I'd suggest that this isn't rea
On 4/17/11, Mike Ratcliffe wrote:
> I remember going over a few hundred thousand lines of JavaScript and adding
> semicolons because I had decided to minify it. I also remember that for
> months I was receiving bug reports from sections of code where I had missed
> the semicolons.
>
> Now I am obs
I remember going over a few hundred thousand lines of _javascript_ and
adding semicolons because I had decided to minify it. I also
remember that for months I was receiving bug reports from sections
of code where I had missed the semicolons.
Now I am obsessed with a
On Apr 13, 2011, at 6:14 AM, Kyle Simpson wrote:
> Many JSON serializer implementations escape the "/" character, including for
> instance PHP's json_encode(). However, JavaScript's own JSON.stringify() does
> not. If you look at the grammar on json.org, as I read it, the escaping of
> "/" is
On 17.04.2011 21:07, Garrett Smith wrote:
On 4/17/11, Brendan Eich wrote:
On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
[TLDR]
ASI is not going to be removed. I don't know why you think it could be.
Why not? Iif developers would stop doing that then eventually, can't
it be removed?
It
I’m a developper and I don’t want to phase ASI out.
If you consider Visual Basic .NET, they are starting to
relax line ending, and it’s really appraised.
Typing semicolons is pointless. It doesn’t add any value
to your code. It only takes time.
From: Garrett Smith
Sent: Sunday, April 17, 2011
On 4/17/11, Brendan Eich wrote:
> On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
[TLDR]
> ASI is not going to be removed. I don't know why you think it could be.
>
Why not? Iif developers would stop doing that then eventually, can't
it be removed?
It is not hard at all to write code that does
Ah, sorry, I'd overlooked the subject line so I didn't realize you were talking
about value proxies. I haven't digested the design space for value proxies, so
I don't have anything to say about this yet. (Value proxies will not be in
ES.next; they're still in a fairly early stage of design.)
Da
Claus,
Thanks for the suggestions. Let me see if I can summarize them and respond
briefly:
* functions with expression bodies
This was proposed for ES4 and implemented in SpiderMonkey. I believe there are
some unfortunate ambiguities in the grammar that came up, and I think they've
been treat
By overwriting I meant creating a trap for === operator. Sorry for confusion.
Adam
2011/4/17 David Herman :
> I don't understand. What is "overwriting" an operator?
>
> Dave
>
> On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote:
>
>> Hello everyone,
>>
>> My idea is to disallow overwriting of =
I don't like this idea. It's inconsistent with the behavior of the other traps,
it relies too subtly on a funky stateful idiom, and it's hard to predict when
the traps will actually fire (since it depends on how clients use the proxy).
If there's something being set once-and-for-all I prefer it
We've talked about this on TC39. We'll probably do something, but exactly what
is hard to say at this point. Designing future-proof pragma syntax requires a
bit of gazing into the crystal ball...
Dave
On Apr 17, 2011, at 2:13 AM, Claus Reinke wrote:
> Pragmas (ignorable source hints to an impl
I don't understand. What is "overwriting" an operator?
Dave
On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote:
> Hello everyone,
>
> My idea is to disallow overwriting of === operator, and make 'compare'
> operator implement == instead. Why?
>
> 1. === means for me that two variables have re
The const functions proposal isn't about referential transparency. They still
encapsulate mutable state. What makes them "const" are the frozen property
table (recall that functions in ES are objects) and the local name that's bound
to the function.
Dave
On Apr 17, 2011, at 1:06 AM, Claus Rein
Hello everyone,
My idea is to disallow overwriting of === operator, and make 'compare'
operator implement == instead. Why?
1. === means for me that two variables have reference to the same
object, so there is no point of overwriting it. Many programmers would
be confused.
2. == always caused prob
On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
> - there is no rule-of-thumb understanding (programmers
> have to look up or memorize all restricted productions,
Here is a quibble: there is a rule, or set of rules enumerated by restricted
productions.
So indeed, viewed production by product
On Sun, Apr 17, 2011 at 4:06 AM, Claus Reinke wrote:
> Short version:
>
> Javascript closures bind their free variables by reference;
> what does that mean for const functions?
>
> Consider extreme cases like this (is this currently permitted?)
>
> var real_f;
> const f() { return real_f()
The idea of ASI seems to be to reduce syntactic clutter, possibly
making programs more readable, which is a laudable goal. But
if the reduction in symbol noise comes at the cost of a rise in
complexity of error-prone interpretation, that actually reduces
readability. And few things frustrate progr
Pragmas (ignorable source hints to an implementation) have
become fairly wide-spread in Javascript, but their look and
usage differs widely, and with an increasing number of tools
defining their own pragma conventions, it is only a matter of
time before they start stepping on each others toes.
Th
Short version:
Javascript closures bind their free variables by reference;
what does that mean for const functions?
Consider extreme cases like this (is this currently permitted?)
var real_f;
const f() { return real_f(); }
This make me wonder what it means for a function to be cons
30 matches
Mail list logo
