On Tue, Aug 19, 2008 at 1:00 AM, Ingvar von Schoultz
[EMAIL PROTECTED] wrote:
From the descriptions it looks like this could instead use
a syntax based on destructuring assignment, if es-harmony
will have destructuring:
I expect es-harmony to have destructuring bind.
var {toggle: t,
On Wed, Aug 20, 2008 at 8:54 AM, Peter Michaux [EMAIL PROTECTED] wrote:
[...] var means variable but
actually specifies scope also to the surrounding function. function
implies an actual function but JavaScript can have side effects
anywhere. undefined doesn't really mean something is
On Thu, Aug 21, 2008 at 9:27 AM, Brendan Eich [EMAIL PROTECTED] wrote:
Besides the return issue, there are break and continue to consider,
and the arguments object.
And this. At least the this issue can be handled by a moderately
more complex desugaring without renaming: If the original
On Thu, Aug 21, 2008 at 6:34 PM, Brendan Eich [EMAIL PROTECTED] wrote:
js [d,e,f] = foo()
1,2,3
Is this a simultaneous assignment of d,e,f, or does it declare variables d,e,f?
If the first, can you do a swap as
[d, e] = [e, d]
?
--
Cheers,
--MarkM
On Sat, Aug 23, 2008 at 8:36 PM, Peter Michaux [EMAIL PROTECTED] wrote:
(function (x, y) {...})(a, b)
would be quite welcome. It is clear people like this pattern and it is
confusing when the formals and actuals are more than a couple and more
than a couple lines apart.
As Lars pointed out,
First, I'd like to apologize to Sam and the other IBM folks regarding
moving the goal posts. While I have repeatedly stated that I would
prefer decimal not to go in at all, in recent ES3.1 phone calls it
seemed we were coming close enough to closure that I expressed
something along the lines of I
If I'm reading the general sense of the list correctly,
[[Configurable]] is generally preferred to [[Flexible]], so I'll use
that below.
We need to distinguish between
* attributes of a property, such as [[Writable]] and [[Configurable]]
* internal properties of an object, such as [[Prototype]]
On Sun, Aug 24, 2008 at 1:43 PM, liorean [EMAIL PROTECTED] wrote:
And I'd argue that you're wrong there. NaN isn't a single value.
Arithmetically, perhaps not. == and === already represent the
arithmetic semantics of NaN and -0.
Computationally, all NaNs are not observably distinguishable in
On Sun, Aug 24, 2008 at 3:22 PM, Kris Zyp [EMAIL PROTECTED] wrote:
I don't see why it is better to have classes be sugar for closured object
literals rather than prototype based structures. It seems the benefits that
are being sought after are auto-binding on method extraction and private
On Sun, Aug 24, 2008 at 5:10 PM, Kris Zyp [EMAIL PROTECTED] wrote:
[...] I believe it is still possible to emulate private instance
variables with prototypes (although much more awkward than with a private
attribute). I could demonstrate if desired.
I desire. Please do. Thanks.
--
On Sun, Aug 24, 2008 at 7:38 PM, Sam Ruby [EMAIL PROTECTED] wrote:
On Thursday, ISTR Mark arguing that correspond to the same point on
the real number line was close enough to an identical test.
No, I was saying the opposite! If == or === is to mean numeric
equivalence, then it should say
On Sun, Aug 24, 2008 at 7:54 PM, Brendan Eich [EMAIL PROTECTED] wrote:
If === remains as good an indistinguishability test as it is now --
with only the above two exceptions -- then I'd agree we don't need
Object.eq. Libraries could provide it without undue burden. However,
assuming you agree
On Sun, Aug 24, 2008 at 8:09 PM, Sam Ruby [EMAIL PROTECTED] wrote:
All things considered, I would argue for false.
I'm curious. If 1.0m == 1.00m were false, what about 1.0m 1.00m and
1.0m 1.00m?
--
Cheers,
--MarkM
___
Es-discuss mailing
On Sun, Aug 24, 2008 at 11:20 PM, Brendan Eich [EMAIL PROTECTED] wrote:
Yes, this is gross. I'm in favor of Object.identical and Object.hashcode,
I don't care if Object.eq is named Object.identical. Other than
spelling, does your Object.identical differ from Object.eq? If not,
then I think we're
On Mon, Aug 25, 2008 at 6:50 AM, P T Withington [EMAIL PROTECTED] wrote:
FWIW, as a user, I've always assumed:
== : equal [1]
[1, 2] == [1, 2] // yields false
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
On Sun, Aug 24, 2008 at 12:31 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Aug 23, 2008, at 10:23 PM, Mark S. Miller wrote:
On Sat, Aug 23, 2008 at 8:36 PM, Peter Michaux [EMAIL PROTECTED]
wrote:
(function (x, y) {...})(a, b)
would be quite welcome. It is clear people like this pattern
On Mon, Aug 25, 2008 at 1:20 PM, Brendan Eich [EMAIL PROTECTED] wrote:
(I will help on identical/hashcode, btw -- think we're agreeing vehemently
;-).)
;) !!
On Mon, Aug 25, 2008 at 1:20 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Aug 25, 2008, at 6:45 AM, Mark S. Miller wrote:
What
I wrote:
Since generators are shallow, it seems clear that there
should be some local cps-style transform of generators into the
remainder of the language. However, it would be a relief to know what
that cps-style transform actually looks like, and what edge cases it
has. Anyone care to post
On Fri, Aug 22, 2008 at 7:27 AM, Neil Mix [EMAIL PROTECTED] wrote:
Since generators are shallow, it seems clear that there
should be some local cps-style transform of generators into the
remainder of the language. However, it would be a relief to know what
that cps-style transform actually
On Mon, Aug 25, 2008 at 4:33 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Aug 25, 2008, at 4:10 PM, Mark S. Miller wrote:
are shallow generators
implementable by a local cps transform?
Yes, the local evaluation (inside the generator function) is the only place
that needs to be CPS'ed
On Mon, Aug 25, 2008 at 7:24 PM, Dave Herman [EMAIL PROTECTED] wrote:
But I'd still rather not try to understand generators
by CPS-transforming the relevant bits of the RI.
A little confused here-- was that an errant not?
No. I meant that, since I understand continuation by CPS-transform, if
On Wed, Sep 3, 2008 at 9:49 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
I don't see why any special case is needed here, or why removing it
would require splitting [[Deletable]] from [[Configurable]].
Suppose that [[Configurable]] = false prevents a writable data property
from being
On Wed, Sep 3, 2008 at 10:58 PM, Brendan Eich [EMAIL PROTECTED] wrote:
If deletable and
configurable were distinct, we could make new properties of the global
object start as configurable but not deletable.
Saving perf but to what end? Does the Caja, etc. programming model
require
On Tue, Sep 9, 2008 at 9:21 AM, Mark S. Miller [EMAIL PROTECTED] wrote:
What should be the rules for coercing non-object 'this' values?
In a previous thread we've already settled that ES3.1-strict will not
coerce null or undefined 'this' values. In order to do this, we're
going to migrate
On Tue, Sep 9, 2008 at 9:21 AM, Mark S. Miller [EMAIL PROTECTED] wrote:
How to restrict 'arguments' in strict functions?
anticipation of ES-H-strict -- prohibit co-existence with splat
arguments.callee
joining? frozen?
If we were making the jump from ES3 directly to ES-Harmony, we
On Tue, Sep 9, 2008 at 9:51 PM, Brendan Eich [EMAIL PROTECTED] wrote:
I have also assumed the existence of a static Function.apply which
takes the function to be applied as an explicit first argument.
This was part of ES4 and it's in JS1.7+ in Firefox.
Since the function constructor is itself
On Thu, Sep 11, 2008 at 11:11 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 9, 2008, at 11:11 AM, Mark S. Miller wrote:
On Tue, Sep 9, 2008 at 9:21 AM, Mark S. Miller [EMAIL PROTECTED] wrote:
What should be the rules for coercing non-object 'this' values?
In a previous thread we've
On Mon, Sep 15, 2008 at 6:16 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 16, 2008, at 1:54 AM, Mark S. Miller wrote:
This is also badly incompatible. Global functions are used as methods of
their window objects. Calling them via this.func() or otherFrame.func()
works, but so do calls
On Mon, Sep 15, 2008 at 7:28 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
Agreed that this proposal does not prevent this existing confusion.
Neither
does it make it worse. If there's something we can plausibly do to fix
this,
I'd love to! Any suggestions?
The problem here is the
On Mon, Sep 15, 2008 at 8:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Sep 15, 2008, at 7:51 PM, Mark S. Miller wrote:
On Mon, Sep 15, 2008 at 6:16 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 16, 2008, at 1:54 AM, Mark S. Miller wrote:
This is also badly incompatible. Global
On Wed, Sep 17, 2008 at 10:53 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I think it is a tenable position that 1.5m === 1.5000m based on the
cohort concept, since performing the same operation on both will give
answers that are in the same cohort equivalence class. But 1.5 / 10.0 !=
1.5m
On Thu, Sep 18, 2008 at 7:54 AM, Sam Ruby [EMAIL PROTECTED] wrote:
2008/9/17 Mark S. Miller [EMAIL PROTECTED]:
If that is the case then 1.5m / 10.0 != 1.5 / 10.0, and thus it seems
wrong for 1.5m and 1.5 to be '==='.
0/-0 != 0/0. Does it thus seem wrong that -0 === 0?
Just so
The Redmond mtg is fast approaching. We'd like to put out an official
for-Redmond-mtg draft of the ES3.1 spec by then. I had volunteered to write
the spec for Function.prototype.bind(). Long term, I think we all agree we'd
like to see this spec and many others self-hosted in EcmaScript. However,
On Thu, Sep 18, 2008 at 11:05 AM, Mike Shaver [EMAIL PROTECTED] wrote:
On Thu, Sep 18, 2008 at 1:41 PM, Garrett Smith [EMAIL PROTECTED]
wrote:
What pseudo-code style? This:
The pseudo-code style from the existing ES3 spec. An example:
11.3.1 Postfix Increment Operator
The production
On Thu, Sep 18, 2008 at 8:00 AM, Mike Cowlishaw [EMAIL PROTECTED] wrote:
Are -0 and 0 in the same cohort?
In IEEE 754, no:
*2.1.10 cohort: *The set of all floating-point representations that
represent a given
floating-point number in a given floating-point format. In this context
On Thu, Sep 18, 2008 at 3:32 PM, Garrett Smith [EMAIL PROTECTED]wrote:
Is this anywhere close to being what you're looking for?
Yes. I haven't yet read it in any detail, but it definitely has the form I'm
looking for. Thanks!
--
Cheers,
--MarkM
On Thu, Sep 18, 2008 at 4:52 PM, Brendan Eich [EMAIL PROTECTED] wrote:
-0 and 0 are not the same given floating point number. 1/-0 vs. 1/0 and
Math.atan2(-0,0) vs. 0,0 are but two examples.
Yes, I understand their operational difference. Whether that difference
means they are not the same
On Sat, Oct 11, 2008 at 12:52 PM, Peter Michaux [EMAIL PROTECTED] wrote:
Use let (the var replacement declaration form).
Sounds good to me but it is a little confusing to keep track if let
is either in or out of ES-Harmony and if it is partly in then which of
the several JavaScript 1.7 uses
Hi Dave, first, my compliments on your lambda proposal. This should
significantly simplify the core language after expanding sugars --
especially if you succeed at redefining function as desugaring to
lambdas. That would be awesome!
On Sat, Oct 11, 2008 at 5:34 AM, David Herman [EMAIL PROTECTED]
On Sat, Oct 11, 2008 at 3:26 PM, Brendan Eich [EMAIL PROTECTED] wrote:
Of course, let expressions would need lambda-coding no matter what
names were shadowed. The experience gained in JS1.7+ shows more let
block usage than let expression, but expression temporaries (lacking
macros and ignoring
On Sat, Oct 11, 2008 at 4:05 PM, Dave Herman [EMAIL PROTECTED] wrote:
Read the proposal again: the statement form of lambdas *does* return the
value of its last expression; this is what ES3 calls the completion value.
Cool! So why are we still discussing proposed let expressions and let
blocks
On Sun, Oct 12, 2008 at 2:19 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
David-Sarah Hopwood wrote:
{ while (...) let x = ...; }
I was under the impression that such statements should be disallowed,
following the example of JS1.8. In JS1.8 (Fx3), the following are all
syntax errors:
while
On Sun, Oct 12, 2008 at 5:45 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
Since LabelledStatement is included in SubStatement, the following is
allowed in the current ES3.1 draft:
while (...) foo: var x = ...;
This will be corrected in the next version. But the agreed fix is not
to make
On Sun, Oct 12, 2008 at 7:55 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
In ES3.1, this will mean that they normally require braces whenever a
body can introduce variables. There are two classes of exceptions,
shown by these examples:
a) while (...) foo: var x = ...;
b) while (...)
On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
for (var ...) implicitly introduces a block whether or not it
is a substatement. This is a wart of C++/C99/Java syntax that
we have to live with, since too much code relies on it.
Yes, but how do we live with it? The
On Mon, Oct 13, 2008 at 9:27 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
MarkM is right that it just falls out of the natural tail-recursive
encoding of a for loop. I got the above expansion wrong by trying to do
it imperatively, which was silly -- the tail-recursive expansion is much
On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman [EMAIL PROTECTED] wrote:
In the grammar for proposed ES4, LetExpression was under
PrimaryExpression. That's where I'm suggesting LambdaExpression might
fit. IOW:
PrimaryExpression ::= ...
| LetExpression
|
On Thu, Oct 16, 2008 at 5:49 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
[lots of good stuff snipped]
I agree.
The degenerate syntax let {...} allowed by this grammar at first-sight
doesn't seem very useful, until you realize that it has a similar effect
(apart from not preventing
On Tue, Oct 21, 2008 at 3:42 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
What does ES3.1 do if you have both const x and var x at the top level?
It just so happens that we discussed top level const in this morning's
ES3.1 phone meeting. It never occurred to us to ban top level const.
We did
On Mon, Oct 27, 2008 at 12:04 PM, Robert Sayre [EMAIL PROTECTED] wrote:
Pratap Lakshman (VJ#SDK) wrote:
I have uploaded to the wiki (link
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft)
the 27 Oct 2008 draft of the specification for ES3.1. This is in the form of
On Mon, Oct 27, 2008 at 7:11 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
It may be necessary in future to add additional incompatible restrictions
along similar lines to strict mode, for example to support the work on
'Secure ECMAScript'. In that case, it's very likely that code written
The intent of ES3's eval operator is clearly that it at least
approximate the following result:
For certain triples of source code text:
some code a some code b some code c
is equivalent to
some code a eval(some code b) some code c
By placing quotes around some code b, I am not
On Thu, Oct 30, 2008 at 8:35 AM, Brendan Eich [EMAIL PROTECTED] wrote:
[...] Browser intersection semantics make indirect eval global, [...]
I had hoped so. This came up at Redmond, and unfortunately, without
either you or Lars there, I was unable to reconstruct why we thought
it would be
On Thu, Oct 30, 2008 at 11:00 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
In recent WebKit versions, this test prints PASS twice:
prescript
var a = PASS;
function foo(a, b, c) { return b(c); }
document.writeln(foo(3, eval, 'a'));
document.writeln(foo(3, window.eval, 'a'));
/script/pre
According to the ES3.1 spec and the behavior of at least FF3.0.3
[4, -0, 0, NaN, 8].indexOf(0); // yields 1
[4, -0, 0, NaN, 8].indexOf(NaN); // yields -1
This is because indexOf and lastIndexOf are specified in terms of ===
rather than SameValue. Is there any reason not to consider this
First, I'd like to thank Richard Cornford, cc'ed, who provided the
earlier draft of Function.prototype.bind that grew into this one.
Thanks!
Below, I modified Richard's draft according to our agreements in
Redmond. But I'm not happy with its complexity. If we instead specify
that we test in step
With the formatting from the word doc, as converted by other tools:
*15.3.4.5 Function.prototype.bind (thisArg [, arg1 [, arg2, …]])*
The bind method takes one or more arguments, *thisArg * and (optionally) *
arg1*, *arg2*, etc, and returns a new function object by performing the
following steps:
On Mon, Nov 3, 2008 at 10:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm sure people may have an opinion one way or the other, I just don't know
of any Web content actually broken by this in practice. I don't have strong
feelings on the matter in either direction, just reporting our
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
ES3.1 is premised on accepting these dynamics, being originally conceived
as ES3 + reality.
I have heard this repeated many times. I'm not sure where this comes from,
but that has never been the sole conception of
On Mon, Nov 10, 2008 at 4:48 PM, Waldemar Horwat [EMAIL PROTECTED]wrote:
Mark S. Miller wrote:
11. If the [[Class]] property of /G/ is *Function*, then
1. Get the *length* property of /G/.
2. Let /L/ be Result(11a) minus the length of /A/.
What does
On Thu, Nov 13, 2008 at 2:53 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
[...] Strict mode reports many
error conditions, such as accessing a non-existent property of an
object, by throwing an exception. In non-strict mode these
conditions silently cause the operation to be
On Fri, Nov 14, 2008 at 8:25 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
[...]
WebKit has a host class that is identical to the native String class in
every way, except that it compares equal to null and undefined, vended in
rare circumstances.[...]
== or ===?
Could you say more about
Gerald J. Popek and Robert P. Goldberg. Formal Requirements for
Virtualizable Third Generation Architectures. Communications of the ACM,
17(7):412–421, 1974.
http://portal.acm.org/citation.cfm?id=361073
--
Cheers,
--MarkM
___
Es-discuss mailing
On Thu, Nov 20, 2008 at 1:43 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
If all non-ECMAScript-coded methods in the DOM, or other add-on interfaces,
can be Native internal functions rather than Host objects, even if they have
behavior that does not match any predefined native Function,
On Sat, Nov 29, 2008 at 5:40 AM, Lasse R.H. Nielsen [EMAIL PROTECTED]wrote:
Number.prototype.box = function() {
return this;
};
var n = (42).box();
I would prefer to have this refer to a basic value instead when calling
methods on primitive values.
I.e.:
(42).toString()
should not
On Mon, Dec 1, 2008 at 8:47 AM, P T Withington [EMAIL PROTECTED] wrote:
Eh? So:
function () {
var foo = 42;
{|| var foo = 3; }
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
Give the same answer?
No, because you forgot to call it.
Despite my nostalgic longing for Smalltalk, I agree ;). But since the
purpose is to be friendlier to control abstraction patterns, it remains
important to have a *very* lightweight syntax for the no-parameter (thunk)
case. The parameter list between the ^ and the { should be optional.
Btw, I see
On Wed, Dec 3, 2008 at 7:25 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
need?
To: es-discuss@mozilla.org
Peter Michaux wrote:
On Sat, Nov 29, 2008 at 9:49 PM, Mark S. Miller [EMAIL PROTECTED]
wrote:
var self = {
to toString() {
return '' + self.getX() + ',' + self.getY() + '';
},
to getX() { return x; },
to getY() { return y; }
let
On Sat, Dec 6, 2008 at 2:39 PM, Michael Day [EMAIL PROTECTED] wrote:
Hi Peter,
I created a Mozilla ticket in response and one of my comments there
talks about the arguments.caller problem
arguments.caller is not defined by ES 3.0, right?
I think this feature is not helpful for efficient
On Sun, Dec 21, 2008 at 6:22 AM, Dave Herman dher...@ccs.neu.edu wrote:
Lex Spoon wrote:
So I would be interested in a simple syntactic form like Lex's suggestion.
Imagine for a moment the following idea didn't cause parsing problems (it
does, but bear with me). Say we had a
On Sun, Dec 21, 2008 at 1:53 PM, Mark S. Miller erig...@google.com wrote:
reveal getX() { reveal privX };
reveal getY() { reveal privY };
Oops. Should be
reveal getX() { reveal (privX) };
reveal getY() { reveal (privY) };
--
Cheers,
--MarkM
On Mon, Dec 22, 2008 at 1:35 PM, Yuh-Ruey Chen maian...@gmail.com wrote:
TBH, even after substituting more Java-esque keywords like public for
reveal, this just doesn't appeal to my aesthetic sense. The user will
naturally wonder why he should do |reveal (privX)| rather than |return
privX|.
On Mon, Jan 5, 2009 at 4:50 AM, Mark Miller erig...@gmail.com wrote:
Sigh. All occurrences of
pubInstVar: {get: function{return pubInstVar;},
enumerable: true},
in my previous messages should be
pubInstVar: {get: Object.freeze(function{return pubInstVar;}),
On Thu, Jan 8, 2009 at 8:57 AM, Dave Herman dher...@ccs.neu.edu wrote:
[NB: I agree with Mark that we should not focus too much on concrete syntax
yet, so I'll also plead for people to avoid quibbling with details of syntax
for the moment.]
Instead of reveal I'd prefer block expressions with
Currently, according to the draft ES3.1 spec
String.prototype.reverse = function() {
use strict;
if (this === '') { return this; }
return this.substring(1).reverse() + this.charAt(0);
};
String.prototype.reverse.call(hello) // 1) works
hello.reverse.call(hello)
First, let me acknowledge that there's been a long history of attempts to
add operator overloading to EcmaScript, that these have all died for various
reasons leaving much documentation in its wake, and that I have not read
this documentation at the present time. If I am simply rehashing ideas
On Thu, Jan 8, 2009 at 9:30 PM, Brendan Eich bren...@mozilla.com wrote:
The rationale we dare not break applies to other cases of making the
strict mode migration tax too high. This came up in the wiki just now, and
I've commented in-line at
On Wed, Jan 14, 2009 at 9:19 AM, Peter Michaux petermich...@gmail.comwrote:
The requirement that JavaScript needed to look like Java has long been
lamented. One of the key looks was the new keyword. Many people
don't like the use of the new keyword. Although new is here to
stay, could we
On Wed, Jan 14, 2009 at 11:58 AM, Juriy Zaytsev kan...@gmail.com wrote:
Are there any plans to include such facility in ES3.1 (or any objections
against it?)
Definitely not in ES3.1 -- it's too late.
Possibly for ES-Harmony, if someone posts a fleshed out proposal (hint hint
;)).
--
On Fri, Jan 9, 2009 at 2:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Jan 9, 2009, at 1:58 PM, Brendan Eich wrote:
Probably much current aliasing is more of a source of buggy behavior than
a feature used intentionally.
Another guess/assertion, but browser vendors cannot compete
On Wed, Jan 14, 2009 at 7:08 PM, Brendan Eich bren...@mozilla.com wrote:
When in doubt, use brute force. ES3 already did. Quoting from its spec for
Function.prototype.apply:
*15.3.4.3 Function.prototype.apply (thisArg, argArray)*
[...] Otherwise, if *argArray *is neither an array nor an
I'm reading the MTV spec, and first I'd like to complement all those who
contributed to it, especially Pratap and Allen who have done a monumental
job. Thanks guys!
Before filing a bug, I wanted to double check: On the strict mode
restrictions of 12.5.1 and 12.6; didn't we decide to drop these
Likewise 12.11.1
On Thu, Jan 15, 2009 at 3:19 PM, Mark S. Miller erig...@google.com wrote:
I'm reading the MTV spec, and first I'd like to complement all those who
contributed to it, especially Pratap and Allen who have done a monumental
job. Thanks guys!
Before filing a bug, I wanted
15.2.3.8 Object.seal(O) and 15.2.3.9 Object.freeze(O) both end with the
qualification
The above algorithm is specified as a set of sequential steps that include
the possibility of a exception
being thrown as various intermediate points. Rather than failing after a
partial update of O, this
I see that the spec for constructing an array from an array literal has been
clarified to ensure that, even if Array.prototype[3] is an accessor
property, that it's setter is not invoked to initialize the corresponding
element of the array. (This issue didn't arise in ES3 since it had no
accessor
On Thu, Jan 15, 2009 at 7:35 PM, David-Sarah Hopwood
david.hopw...@industrial-designers.co.uk wrote:
Brendan Eich wrote:
On Jan 15, 2009, at 5:42 PM, David-Sarah Hopwood wrote:
Allen Wirfs-Brock wrote:
I generally agree that it would be a good idea to specify apply (and
call)
pretty
On Fri, Jan 16, 2009 at 5:34 PM, Brendan Eich bren...@mozilla.com wrote:
Have you looked at multimethods in Cecil?
http://www.cs.washington.edu/research/projects/cecil/pubs/cecil-oo-mm.html
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.8502
On your recommendation, I have. I
The Mountain View draft says:
15.1.2Function Properties of the Global Object
15.1.2.1eval (x)
When the eval function is called with one argument x, the following steps
are taken:
[...]
If the value of the eval property is used in any way other than a direct
call (that is, other
On Sun, Jan 18, 2009 at 4:35 PM, Brendan Eich bren...@mozilla.com wrote:
We also allow keywords as property names in JS1.7+ and did for ES4 -- this
relaxation from current context-free reservation of identifiers has been
talked about for 3.1 too, and IIRC it was agreed to for Harmony at last
On Sun, Jan 18, 2009 at 12:47 PM, Mark S. Miller erig...@google.com wrote:
The Mountain View draft says:
15.1.2Function Properties of the Global Object
15.1.2.1eval (x)
When the eval function is called with one argument x, the following steps
are taken:
[...]
If the value
On Sun, Jan 18, 2009 at 8:47 PM, Brendan Eich bren...@mozilla.com wrote:
On Jan 18, 2009, at 6:03 PM, Mark S. Miller wrote:
A related difficulty, not addressed by the above spec, is shadowing. Does
the following program contain a direct call to eval (i.e., a use of the
eval operator
On Sun, Jan 18, 2009 at 10:17 PM, Mark S. Miller erig...@google.com wrote:
Though the above specific problem cannot occur if foo is strict, I propose
that, for all code, one may not define a local variable named eval.
This is unnecessary, and I'm not sure it's sufficient given your
On Sat, Jan 24, 2009 at 9:17 PM, Peter Michaux petermich...@gmail.comwrote:
As an idea, I just ran the following code in Firefox and it did do
what I expected. It makes it possible to pass around a plain function
object that will construct.
Function.prototype.__defineGetter__(make,
On Fri, Jan 30, 2009 at 12:19 AM, Garrett Smith dhtmlkitc...@gmail.comwrote:
No offense, but that is some ugly code.
Indeed. We wouldn't have written it if the language didn't force us to.
[...]
To supply varargs to that constructor, use a newApply function.
Function newApply, for a
2009/2/10 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com
Mark Miller said: We can get the effect of specifying such
indistinguishability simply by specifying that host objects may have as
their [[Class]] property Object, or any string not otherwise used by the
spec as a [[Class]] value.
On Tue, Feb 10, 2009 at 6:42 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Good, so back to the original questions.
Do we remove the current permission to throw EvalError? [I vote yes]
Once it's gone what do we do with the EvalError object? [I vote leave it in
the spec.
On Tue, Feb 10, 2009 at 7:50 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
However, now that I think a little bit more about, it would be reasonable
to say that any strict mode declaration of eval is an EvalError. I was
going to say it was a SyntaxError but EvalError is more
On Wed, Feb 11, 2009 at 8:27 AM, David-Sarah Hopwood
david.hopw...@industrial-designers.co.uk wrote:
Note that the algorithms in the JSON section check whether [[Class]] is
Array directly; they should probably be using Array.isArray.
Why? If someone assigns a different function to
On Wed, Feb 11, 2009 at 8:22 AM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Declaration binding instantiation creates an array object for a function
only if the function does not have any explicit declarations named
arguments. However, there is currently no strict mode
1 - 100 of 1628 matches
Mail list logo
