On Sun, Jul 27, 2008 at 9:15 PM, Ingvar von Schoultz
[EMAIL PROTECTED] wrote:
Does it matter whether it's interpreted as an empty block or
an empty discarded array?
It's not always discarded:
js var x = 1
js eval (if (x) [1, 2, 3])
1,2,3
Mike
___
2008/7/24 Mike Cowlishaw [EMAIL PROTECTED]:
It is expected that anyone who does receive a copy will handle it
professionally, not distribute it further, etc.
What is the expectation with respect to downstream work based on the
spec? If we start adding test cases or fixing bugs in our codebase
On Mon, Jul 14, 2008 at 11:08 AM, Sam Ruby [EMAIL PROTECTED] wrote:
Mike Shaver wrote:
I can't see why not -- we'll certainly be looking to implement
forthcoming editions of ECMAScript, and if decimal is a part of it
then your code would certainly be helpful!
Did you say if? Grrr
Yes
On Mon, Jul 14, 2008 at 4:37 PM, Mike Cowlishaw [EMAIL PROTECTED] wrote:
(The decNumber code is quite stable, for example -- averaging fewer than one
detected bug/year since its first release in 2001, is used in numerous IBM,
SAP, and other vendors' products, and is part of the verification
On Thu, Jul 10, 2008 at 1:48 AM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.
You need to have an advance specification
On Thu, Jul 10, 2008 at 8:54 AM, Sam Ruby [EMAIL PROTECTED] wrote:
Decimal is a library addition. A superset of whatever gets proposed for
ES3.1 should be included in ES4. Brendan mentioned four places where ES4
implementation work is either occurring or intended to occur:
SpiderMonkey
On Thu, Jul 10, 2008 at 9:55 AM, Sam Ruby [EMAIL PROTECTED] wrote:
Library additions have less of a concern for interaction with real-world
content, but the idea of inserting the code into something that will
ultimately ship does appeal to me. If I were to do the work to put this
code into
2008/7/9 Maciej Stachowiak [EMAIL PROTECTED]:
Although the standard does not allow block-level function declarations
I'd understood that, while ES3 didn't specify such declarations, it
was not a violation of the standard to have them. I agree with your
assessment of the compatibility impact,
2008/5/27 Maciej Stachowiak [EMAIL PROTECTED]:
It could save a lot of complexity, by not requiring any first-class support
for namespace lookup on arbitrary objects.
Is the expectation then that having two lookup models, one for global
objects and the other for non-global objects, going to
On Sun, May 18, 2008 at 10:50 AM, Steven Mascaro [EMAIL PROTECTED] wrote:
For example, suppose that it were possible to retrieve the text of any
script src=.../script element using '.textContent' from
javascript, regardless of origin. You'll agree that this is
unthinkable today. But I assume
On Wed, May 7, 2008 at 12:17 PM, Erik Arvidsson
[EMAIL PROTECTED] wrote:
The quote method needs more specification. It needs to escape a lot
more characters than just single and double quotes. The basic rule is
that String.prototype.quote should return a string that would be a
valid
On Wed, Apr 16, 2008 at 1:08 PM, David Flanagan [EMAIL PROTECTED] wrote:
David Flanagan wrote:
If there is no way to turn assertions off, and since the spec requires
the parentheses around the assertion, I don't see what is gained by
making this a expression instead of a global
On Thu, Mar 27, 2008 at 7:06 AM, David Teller
[EMAIL PROTECTED] wrote:
In my experience, the main problem with JS was the impossibility of
extending it. That is, no notion of libraries and no built-in
pre-processor (although reflexivity could be used for similar purposes).
A consequence
On Sun, Mar 23, 2008 at 2:44 AM, Dean Edwards [EMAIL PROTECTED] wrote:
I'd prefer Array.forEach(null) to do nothing, just like for (var i in
null) does nothing. I'm prepared to be convinced otherwise. :-)
forEach isn't like enumeration, though, it's like the more common
Array pattern of
for
On Sat, Mar 22, 2008 at 1:42 PM, Garrett Smith [EMAIL PROTECTED] wrote:
Array generic methods will be safer if they check their args and throw
an error - InvalidArgumentError, TypeError, UnlikeError - (whatever).
Invalid: (this will crash Firefox with endless loop):-
Array.forEach( {
On Sat, Mar 22, 2008 at 4:32 PM, Dean Edwards [EMAIL PROTECTED] wrote:
Dean Edwards wrote:
I think that the problem is that Array generics were added later.
From bugzilla:
Array.generic(t, ...) is *intended* to be equivalent to
Array.prototype.generic.call(t, ...).
On Thu, Mar 20, 2008 at 12:27 PM, Lars Hansen [EMAIL PROTECTED] wrote:
A comment of this form preceded on the same line only by whitespace:
/**es:context=scheme;data;line*/
We did this with // comments in SpiderMonkey, because the directives
are inherently related to a line, and it avoids
On Mon, Mar 17, 2008 at 5:36 PM, Brendan Eich [EMAIL PROTECTED] wrote:
For backward compatibility with SpiderMonkey, one might like 2' to
make a getter that can be deleted.
That pattern is used in Firefox now (and perhaps elsewhere) to do lazy
initialization of expensive objects:
On Mon, Mar 17, 2008 at 6:14 PM, Brendan Eich [EMAIL PROTECTED] wrote:
With only SpiderMonkey supporting __defineGetter__, it's not widely
used. The canonical JS memoization pattern, presented nicely here:
Yeah, I would expect that only properties of new objects are lazily
defined that way,
On Sun, Mar 9, 2008 at 12:11 PM, Michael Daumling [EMAIL PROTECTED] wrote:
I agree that file and line information is not really sensitive
information.
I disagree: we have existing bugs in Mozilla about the security impact
of exposing filename information to unprivileged callers. It's likely
On Fri, Mar 7, 2008 at 7:31 AM, Lars Hansen [EMAIL PROTECTED] wrote:
The chances that the spec will *require* a useful backtrace
(quasi-fixed format and requirements about which frames may or
may not be in it, say) or source location information to be
created for E.p.throw are probably
On Dec 18, 2007 9:52 AM, João Eiras [EMAIL PROTECTED] wrote:
Being able to define the () (function call), [] (indexing) and typeof
operators is a must.
At least function call and property access are indeed customizable
(via a meta-object protocol rather than operator overloading).
Mike
On 10/11/07, Garrett Smith [EMAIL PROTECTED] wrote:
If an object accepts arguments, it is callable, and if it is callable,
it supports ,call(), right?
Assuming you mean has itself a Callable member named 'call', then I
think the answer is no -- being Callable means having a [[Call]]
operation
23 matches
Mail list logo
