> 1) It's disallowed, Array instances can't have own accessor properties with
> array index names. (and since Array.prototype is an Array instance it can't
> either. An array instance could only inherit an accessor property with an
> array index name from Object.prototype)
>
(snip)
>
> My preferenc
In Mountain View and/or in earlier discussions there was agreement that Array
instances needed a special version of [[DefineOwnProperty]] that ensures that
the array length invariants are properly maintained in the presence of
Object.defineProperty and friends. I'm working on that now and runni
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich wrote:
> We should talk about methodMissing for Harmony.
I did try
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008143.html
but nothing seems to have come of it yet
http://wiki.ecmascript.org/doku.php?id=strawman:strawman
Pete
On Feb 13, 2009, at 11:42 AM, Allen Wirfs-Brock wrote:
Can you get off the fence on adding goto? How about call/cc?
For now, I only have problems, not solutions.
Me too :-).
However, I think it is debatable whether call/cc is more
approachable to beginners (who admittedly don't write com
>
>Can you get off the fence on adding goto? How about call/cc?
>
For now, I only have problems, not solutions. However, I think it is debatable
whether call/cc is more approachable to beginners (who admittedly don't write
compilers) than goto. Call/cc is probably less of an attractive nuisance
On Feb 13, 2009, at 11:23 AM, Brendan Eich wrote:
Tail calls is another feature I think benefit both especially as
interest in functional languages is rising
strongly.
I happen to agree, but these already foundered during ES4 development.
More recently, Waldemar objected to lambdas due to
On Feb 13, 2009, at 11:10 AM, Peter Michaux wrote:
On Fri, Feb 13, 2009 at 10:51 AM, Brendan Eich
wrote:
JS is used by many more programmers, amateur and pro, than C. It
has to have
better human factors than C. That goes against being a good code
generator
target language.
I think tha
On Feb 13, 2009, at 11:07 AM, Allen Wirfs-Brock wrote:
Brendan Eich wrote:
...
JS is used by many more programmers, amateur and pro, than C. It has
to have better human factors than C. That goes against being a good
code generator target language.
I totally agree with the first two sentenc
On Fri, Feb 13, 2009 at 10:51 AM, Brendan Eich wrote:
> JS is used by many more programmers, amateur and pro, than C. It has to have
> better human factors than C. That goes against being a good code generator
> target language.
I think that may not be true in all cases. methodMissing is an exam
>> Brendan Eich wrote:
...
>
>JS is used by many more programmers, amateur and pro, than C. It has
>to have better human factors than C. That goes against being a good
>code generator target language.
>
I totally agree with the first two sentences. I reserve judgment regarding the
third.
Allen
On Feb 13, 2009, at 9:46 AM, Allen Wirfs-Brock wrote:
I ending up using EvalError for the strict mode situations where we
forbid declaration of "eval".
+1, FWIW.
/be
-Original Message-
From: Waldemar Horwat [mailto:walde...@google.com]
Sent: Thursday, February 12, 2009 4:58 PM
T
On Feb 13, 2009, at 9:44 AM, Allen Wirfs-Brock wrote:
I'm not yet convinced that this really is a significant ES3 to ES3.1
compatibility issues.
Not sure either, why I wrote "I can't prove this is going to burn
programmers in the future, but I suspect it will."
I don't see that the speci
On Feb 13, 2009, at 7:45 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
If a "common language for hand-coders and code-generators" is
desirable, isn't it necessary to consider the code-generator part?
Yes.
I didn't agree that such a de
I haven't digested the details of this thread. However, I did want to go on
record as saying this is an area of interest to Microsoft and something we
would like to put more effort into (in the TC-39 context) after we wrap-up
ES3.1. Now back to trying to finish editing for the final draft ES3.
The easiest place to ban it would be in PutValue as References now carry
sufficient state to identify them as simple identifier bindings in strict mode.
Allen
From: Mark Miller [mailto:erig...@gmail.com]
Sent: Thursday, February 12, 2009 5:24 PM
To: Waldemar Horwat
Cc: Allen Wirfs-Brock; es-disc
I ending up using EvalError for the strict mode situations where we forbid
declaration of "eval".
>-Original Message-
>From: Waldemar Horwat [mailto:walde...@google.com]
>Sent: Thursday, February 12, 2009 4:58 PM
>To: Brendan Eich
>Cc: Mark S. Miller; Allen Wirfs-Brock; Chris Pine; es-
>d
>ES3.1 changes the rules to use CreateMutableBinding when entering the
>eval execution context only if x is not already bound, and in any case
>then to call SetMutableBinding (10.2.1.2.3 in the feb09 draft).
>SetMutableBinding calls [[ThrowingPut]]. Strict mode adds value in its
>own way but let's
Brendan Eich wrote:
> On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
>
>> If a "common language for hand-coders and code-generators" is
>> desirable, isn't it necessary to consider the code-generator part?
Yes.
> I didn't agree that such a desert-topping/floor-wax was desirable.
Almost all p
Allen Wirfs-Brock wrote:
> Now that we have decided that all declarations of the identifier
> "eval" are banned from strict code a related question has come up
> from one of the implementers of our strict mode prototype implementation.
> Why does Es3.1 still allow assignment to the identifier "eval
19 matches
Mail list logo
