On Aug 23, 2008, at 6:54 AM, Mike Cowlishaw wrote:
Maciej Stachowiak [EMAIL PROTECTED] wrote:
Finally, I'd like to take a poll: Other than people working on
decimal
at IBM and people on the EcmaScript committee, is there anyone on
this
list who thinks that decimal adds significant
On Aug 23, 2008, at 11:30 AM, Sam Ruby wrote:
[EMAIL PROTECTED] wrote:
On Sat, Aug 23, 2008 at 10:04 AM, Sam Ruby [EMAIL PROTECTED]
wrote:
Decimal implemented as a library would be sufficient for a 3.1
release. The problem is an interoperable definition for what infix
operators is
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 functions are used as
methods of their window objects. Calling them via
On Sep 17, 2008, at 10:06 PM, Mark S. Miller wrote:
0/-0 != 0/0. Does it thus seem wrong that -0 === 0?
Well, yes, actually it does seem wrong to me, but we all accept
that particular wrongness. This is just more of the same.
A lot more.
Two wrongs don't make a right.
One exception
On Sep 18, 2008, at 5:13 PM, Mark S. Miller wrote:
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.
On Sep 18, 2008, at 6:03 PM, Mark S. Miller wrote:
On Thu, Sep 18, 2008 at 5:22 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Sep 18, 2008, at 5:13 PM, Mark S. Miller wrote:
On Thu, Sep 18, 2008 at 4:52 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
-0 and 0 are not the same given
On Sep 24, 2008, at 8:41 AM, Michael wrote:
Maciej wrote:
“I'm not sure what you are getting at. a[1] and a[1.000] refer to the
same property in ECMAScript, but a[1m] and a[1.000m] would not. Are
you saying this isn't a problem?”
This is not quite true as you can see here:
var a = [];
a[1] =
On Sep 24, 2008, at 9:01 AM, Mike Cowlishaw wrote:
I would agree with Waldermar that it is a serious problem. Not so
much
for literals as for values that end up with varying numbers of
trailing zeroes depending on how they were computed, even though they
are numerically the same.
On Sep 26, 2008, at 12:38 AM, Karl Krukow wrote:
My suggestion is to strengthen the contract to state something like:
For any function f and any values x1, x2, ... , xn we have:
eval(f.toString())(x1,x2,...,xn) === f(x1,x2,..., xn).
I would agree with such a requirement, but only in the
On Sep 26, 2008, at 3:27 AM, Karl Krukow wrote:
On 26/09/2008, at 11.13, Maciej Stachowiak wrote:
I would agree with such a requirement, but only in the case where
the eval(f.toString()) is performed in the same scope where f was
originally defined, since toString does not represent
On Oct 16, 2008, at 7:01 PM, Brendan Eich wrote:
On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote:
On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
I don't think you can come up with a consistent shift or
greedy notion.
Funny, yacc has had one for decades, used to resolve
On Oct 17, 2008, at 11:17 AM, Waldemar Horwat wrote:
Maciej Stachowiak wrote:
As to the else issue, I don't think that ambiguity can be avoided,
but bison lets you solve that with %nonassoc, which is a sound
disambiguation mechanism.
It can. I have a machine-validated ES3 (and ES4
On Oct 20, 2008, at 2:23 PM, Dave Herman wrote:
Yes, that's what I was referring to earlier. Do you now understand
my
mail from 10/17/2008 12:39?
You mean these examples?
lambda h(x) {
switch (x) {
case 1:
g();
break;
case 2:
...
}
}
I doubt there's any clean
On Oct 21, 2008, at 6:14 PM, Waldemar Horwat wrote:
Maciej Stachowiak wrote:
I don't think you can represent tail position in a switch statement
with your attribute grammar notion, but it's clear to me that the
statement immediately before a break statement, or else the last
statement
On Oct 27, 2008, at 6:46 AM, Dave Herman wrote:
Maciej Stachowiak wrote:
You could probably define a rigorous transform to apply to a
swtich() statement that turns it into a series of if / else clauses
(possibly duplicating later cases if there is no break) and apply
the usual if rule
On Oct 27, 2008, at 4:54 PM, David-Sarah Hopwood wrote:
Robert Sayre wrote:
I checked current browser behavior for this coercion to the global
object for array methods (as well as apply and call).
Opera 9.61
Chrome Beta 1
Safari 3.1.2
Firefox 3.0.3
On Oct 27, 2008, at 5:13 PM, Dean Edwards wrote:
Maciej Stachowiak wrote:
On Oct 27, 2008, at 4:54 PM, David-Sarah Hopwood wrote:
Robert Sayre wrote:
I checked current browser behavior for this coercion to the global
object for array methods (as well as apply and call).
Opera 9.61
Chrome
On Oct 27, 2008, at 11:28 PM, Breton Slivka wrote:
I would argue it. You can either equivalently consider the fall
through to
be a jump, or say it behaves as if the code of case 2
as if the code of case 2 were duplicated into case 1
- Maciej
I had a go at combining that concept with my
On Oct 28, 2008, at 12:46 PM, Peter Michaux wrote:
I do roughly the same thing. Using an object is faster than switch
also, as far as I recall doing some tests. The speed of switch seems
to be the same speed as if-else if-else if-...-else.
It really depends on what you are doing. At least
On Oct 29, 2008, at 11:23 PM, Mark S. Miller wrote:
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
On Oct 30, 2008, at 10:20 AM, Mark S. Miller wrote:
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
On Oct 30, 2008, at 11:12 AM, Mark S. Miller wrote:
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
On Oct 30, 2008, at 12:24 PM, Brendan Eich wrote:
On Oct 30, 2008, at 10:20 AM, Mark S. Miller wrote:
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
On Oct 30, 2008, at 1:09 PM, Brendan Eich wrote:
On Oct 30, 2008, at 12:58 PM, Maciej Stachowiak wrote:
On Oct 30, 2008, at 12:24 PM, Brendan Eich wrote:
Probably when we started, we had the Firefox 1.0-1.5 behavior
(JS1.5-1.6) in mind. Since then, elves fixed bugs. :-/
Still I do
On Nov 3, 2008, at 6:54 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 3, 2008, at 11:34 AM, David-Sarah Hopwood wrote:
Erik Arvidsson wrote:
I see a small risk with changing this. Array.prototype.indexOf is
widely
emulated in IE and is also used a lot in browser
On Nov 3, 2008, at 10:39 PM, Brendan Eich wrote:
On Nov 3, 2008, at 10:26 PM, Maciej Stachowiak wrote:
JavaScriptCore's RegExp objects have been callable since Safari 1.0
Beta 1 and I believe they have returned function from typeof that
whole time. (The Mozilla bug report says otherwise
On Nov 5, 2008, at 5:40 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Nov 5, 2008, at 1:42 PM, David-Sarah Hopwood wrote:
Of course not. In this case we were talking about a case in which IE
and Opera do not implement an extension, and follow the existing
standard
more closely in
Hi Mark,
On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:
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
On Nov 6, 2008, at 7:26 AM, Mark S. Miller wrote:
On Thu, Nov 6, 2008 at 6:46 AM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
ES3.1 is premised on accepting
On Nov 14, 2008, at 8:30 PM, Mark S. Miller wrote:
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
On Nov 17, 2008, at 8:38 PM, David-Sarah Hopwood wrote:
Blake Kaplan wrote:
On 11/15/2008 09:40 PM, Garrett Smith wrote:
Standardizing an MSIE property that works differently than in MSIE
creates compatibility problems on the web. A better alternative
would
be to use a different property
On Nov 17, 2008, at 9:24 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 14, 2008, at 4:48 PM, David-Sarah Hopwood wrote:
Should host objects be required not to have [[Class]] Function?
No, I do not think this is a sounds requirement. All native
functions in
the DOM
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding discussion about lambda syntax and why it matters.
Observation: blocks in Smalltalk being lightweight means users don't
mind writing them for control abstractions,
in). In ECMAScript you can't have them look exactly the same, but I
think the Haskellish backslash style fits in a little better.
Regards,
Maciej
Allen
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak
Sent: Monday, December 01
On Dec 1, 2008, at 5:37 PM, Allen Wirfs-Brock wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Douglas Crockford
...
because you can think of the \ as being an abbreviation of function.
\ name(a,b,c) {}
Just don't start your
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious
in meaning than \ or ||.
Regards,
\. This could support named lambdas without risk of
clashing with the \u escape.
Regards,
Maciej
Regards,
Eric Suen
- Original Message -
From: Allen Wirfs-Brock
[EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Maciej Stachowiak
[EMAIL PROTECTED
On Dec 2, 2008, at 6:57 PM, Brendan Eich wrote:
This loses almost all connection with the rest of the language.
Arguments are passed in a comma separated list. Wrapped in
parentheses. The Smalltalk hommage loses the parens but keeps the
commas. Any other separator is just wrong, sorry.
On Dec 3, 2008, at 6:30 PM, Brendan Eich wrote:
On Dec 3, 2008, at 6:18 PM, Maciej Stachowiak wrote:
x = x
+x
That is equivalent to
x = x + x;
so the case with ^ should not differ. (Were you testing in an
interactive REPL?)
I didn't test, I just knew this case must be disambiguated
On Dec 4, 2008, at 7:18 AM, Michael wrote:
Would this form also be ambiguous and/or too difficult to parse?
{= 9*9}()
{a = a+b}(12)
{(a,b) = a+b}(12,6)
I imagine it would be problematic for a top-down parser because you
may have to parse an unbounded number of characters to determine if
On Dec 4, 2008, at 10:27 PM, Brendan Eich wrote:
On Dec 4, 2008, at 10:12 PM, Brendan Eich wrote:
On Dec 4, 2008, at 7:45 PM, Michael Day wrote:
Hi Brendan,
The main contention about lambdas ignoring syntax is whether the
completion-value creates a hazard that needs to be treated
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by return-to-label that isn't
already raised by exceptions? They're practically the same thing,
only return-to-label is *easier* to analyze statically, because
'return' can only jump to a label that is
On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote:
On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by return-to-label that isn't
already raised by exceptions? They're
On Jan 18, 2009, at 12:47 PM, Mark S. Miller 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 of the eval property is used in
On Feb 17, 2009, at 2:02 PM, Ian Hickson wrote:
Right now ES3 assumes that there is a single global object, which is
used
at the top of the scope chain and that is returned for this in the
global scope.
It is possible to show that this is now what some browsers do:
var x = 1;
On Feb 17, 2009, at 6:31 PM, Mark Miller wrote:
On Tue, Feb 17, 2009 at 5:24 PM, Ian Hickson i...@hixie.ch wrote:
Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE
does,
namely throw an exception when running code whose global object
doesn't
match the current Window
On Feb 17, 2009, at 11:18 PM, Mark Miller wrote:
You misunderstood me a bit, but no matter. Now that I better
understand the constraints -- thanks! -- what I was trying to say is
irrelevant. What I mess. I am at a loss to find anything sensible to
recommend.
I think that's how most of
On Feb 19, 2009, at 1:39 AM, David-Sarah Hopwood wrote:
Ian Hickson wrote:
On Tue, 17 Feb 2009, Mark Miller wrote:
On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch wrote:
Indeed, I noted this earlier. The behavior HTML5 codifies is the
behavior that the majority of browser vendors
On Feb 19, 2009, at 1:20 AM, David-Sarah Hopwood wrote:
Ian Hickson wrote:
On Tue, 17 Feb 2009, Mark S. Miller wrote:
I don't understand. If the object you're calling Window is
inaccessible
from ES code, and if the object you're calling WindowProxy forwards
everything to your Window, why
On Feb 20, 2009, at 3:26 PM, Mark S. Miller wrote:
2009/2/20 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com:
The cop-out is to just leave it as it is.
The safe decision is to mandate the current de facto standard.
The brave (ie, risky) decision for a better long term language is to
On Feb 21, 2009, at 1:49 AM, David-Sarah Hopwood wrote:
Ian Hickson wrote:
Right now ES3 assumes that there is a single global object, which
is used
at the top of the scope chain and that is returned for this in the
global scope.
It is possible to show that this is now what some browsers
On Feb 20, 2009, at 4:13 PM, David-Sarah Hopwood wrote:
Ian Hickson's description of the two objects was:
# The global object is a Window object. This object is per-Document.
# The object returned by the window attribute on that global object
# is actually a WindowProxy object, which forwards
On Mar 1, 2009, at 10:28 AM, Allen Wirfs-Brock wrote:
From: Brendan Eich [mailto:bren...@mozilla.com]
What should (new Function).name or (equivalently) Function().name
return? Precedent in some engines:
js (new Function).name
anonymous
An anonymous function expression returns the empty
On Mar 3, 2009, at 8:01 PM, Mark S. Miller wrote:
I like most of what you just proposed, except that I find it
surprising that a function's .name is not the identifier used by
.toString() on that function. This same issue just came up on an
internal list at Google: Objecting that since
On Mar 4, 2009, at 3:52 PM, Brendan Eich wrote:
On Mar 4, 2009, at 1:38 PM, Jeff Watkins wrote:
Can I suggest that allowing writing to name may be helpful when
creating transparent wrapper functions?
We do a lot of this:
function wrapWithChangeNotification(key, fn)
{
return
On Mar 5, 2009, at 11:18 PM, Brendan Eich wrote:
On Mar 5, 2009, at 9:26 PM, Allen Wirfs-Brock wrote:
In their code generation scheme, do they ever require the generated
function to have a particular non-global scope, or will global
scope do?
Are you really talking about scopes in the
On Apr 16, 2009, at 2:37 PM, kevin curtis wrote:
Hi
Has it been established how browsers will handle ecmascript 5? e.g.
script type=application/ecmascript;version=5 ...
The above is from the es4 proposal with 4 replaced with 5:
http://wiki.ecmascript.org/doku.php?id=proposals:versioning
On May 16, 2009, at 11:25 AM, Mark S. Miller wrote:
On Fri, May 15, 2009 at 2:26 PM, Brendan Eich bren...@mozilla.com
wrote:
[...] but plain old iloop DOS prevention as practiced in browsers
does *not* reload the page. And the browser APIs are full of ways
to detect
that finallys didn't
On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
I suspect we'll see some de-facto stuff come out of one or two
vendors who aren't active in TC39 (Apple, Google V8).
Google is quite active in TC39. Google's representatives to TC39
(including me) are now in close coordination with our
On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
On Mon, Jun 15, 2009 at 9:23 PM, Brendan Eich bren...@mozilla.com
wrote:
For ES5, this is a tempest in a teapot.
We at Mozilla are trying to remove assignable __proto__ in a near-
term release,
Hi Brendan, this is wonderful news!
As
On Jun 17, 2009, at 7:34 PM, Mark S. Miller wrote:
On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak m...@apple.com
wrote:
As to the substantive issue: mutable __proto__ is something we would
prefer not to have, but we are concerned about the compatibility
issues. We look forward
On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:
On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:
On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:
Probably the best thing to do is to provide detailed technical
review of Web IDL via the W3C process.
Expertise on both sides
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become
Invited
Experts to the W3C Web Applications Working Group, if that
facilitates
review.
Unfortunately, no. See #2 and #3
On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote:
Maciej Stachowiak wrote:
On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that
there are parts of WebIDL that are unused. Another is that the
parts of the spec themselves are fairly
On Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote:
To clarify, AFAIK, no one on the EcmaScript committee is proposing
that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript
language binding.
The design of Web IDL itself is highly informed by the ECMAScript
language binding -
On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote:
I will stop the over-citing madness here and now :-P.
The struggle to formalize ArrayLike, which seems like a common goal
for ES the core language and for WebIDL's ES bindings, makes me want
to give an exception to the catchalls considered
On Sep 25, 2009, at 3:34 PM, Krzysztof Maczyński wrote:
Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make
On Sep 25, 2009, at 10:29 PM, Cameron McCormack wrote:
unsigned long doesn’t map exactly to Number. Assigning a Number to an
unsigned long attribute does truncation, for example:
http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long
The case could be made for “float”, which maps to
On Sep 25, 2009, at 11:32 PM, Brendan Eich wrote:
On Sep 25, 2009, at 11:28 PM, Brendan Eich wrote:
We seem to agree, perhaps vehemently :-/.
One last time, for the record: it is a bug in ES specs that you
can't follow th
Sorry, rogue cut before send. it's a bug in ES specs that you
On Sep 26, 2009, at 12:20 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
I think there are two possible perspectives on what constitutes
magnify[ing] the problem or widening the gap
A) Any new kind of requirement for implementations of object
interfaces
that can't be implemented
On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote:
No we are not. This is exactly the heart of our concern. The WebIDL
ECMAScript binding is not simply a mapping of IDL interface onto
standard language features (such as is done for the Java binding).
While it has some of that it also
On Sep 26, 2009, at 3:58 PM, Cameron McCormack wrote:
Cameron McCormack:
Indeed, much of the custom [[Get]] etc. functionality can be
turned into
ES5 meta-object stuff. A pertinent question is then: should we
change
Web IDL to specify an ES5 binding (and not ES3) at this point, given
On Sep 26, 2009, at 4:41 PM, Oliver Hunt wrote:
The specific problem is that host objects cannot necessarily match
the semantics of ES5, and for that reason the interaction of host
objects with the ES5 semantics is unclear.
I think mapping Web IDL behavior to ES5 property descriptors
On Sep 26, 2009, at 3:30 PM, Cameron McCormack wrote:
Yehuda Katz:
Ha. Maybe it would be worth putting a note in HTML5.
[Replaceable] is
a quirk of history. Do not over-attend to it.
Ian Hickson:
If we start calling out all the quirks of history in HTML5, we'd
probably
end up doubling
On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:
-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]
I expect there are relatiively few such capabilities, and little
interest in depending on new ones, and therefore we do not really
have
a general ongoing
On Sep 26, 2009, at 8:05 PM, Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.
Seems like a strong reason to change to the proposed API to
eliminate the need
On Sep 27, 2009, at 12:30 AM, Brendan Eich wrote:
On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:
What does typeof say for such a callable object?
I think it should probably say object, though that's not
compatible with ES3 or current WebKit practice.
ES3 lets host objects
On Sep 27, 2009, at 12:35 PM, Mark S. Miller wrote:
Comparing https://mail.mozilla.org/pipermail/es-discuss/2009-September/
with http://lists.w3.org/Archives/Public/public-webapps/
2009JulSep/ and http://lists.w3.org/Archives/Public/public-html/2009Sep/
shows why this cross posting madness
On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure
ECMAScript. The current proposal does
On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:
On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:
I'm musing a bit here, bear with me. If we only hack
incrementally, and preserve backward compatibility with frankly
dumb (or merely hasty) design decisions (many mine!) then we'll
On Sep 27, 2009, at 12:23 PM, Boris Zbarsky wrote:
On 9/27/09 3:30 AM, Brendan Eich wrote:
I believe we could get rid of custom deleters from the Web
platform if
Firefox and IE remove support for custom deleters in LocalStorage,
refuse to add it back, and refuse to implement it for
On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote:
On Sep 27, 2009, at 00:36 , Cameron McCormack wrote:
Indeed, much of the custom [[Get]] etc. functionality can be turned
into
ES5 meta-object stuff. A pertinent question is then: should we
change
Web IDL to specify an ES5 binding (and not
On Sep 27, 2009, at 12:37 PM, Boris Zbarsky wrote:
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
This is not an issue for DOM methods. It's an issue for interfaces
such
as HTMLCollection and HTMLFormElement that support indexing by
function
call syntax, for legacy compatibility reasons
On Sep 28, 2009, at 10:12 AM, Allen Wirfs-Brock wrote:
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Robin Berjon
There is no old version.
Right, this is v1. What previous W3C API specifications had relied on
was
). Using ES5 as the reference baseline would help
make this more clear perhaps.
- Maciej
This might also be a useful step in the direction that I was hoping
for in some earlier postings.
-- Yehuda
On Mon, Sep 28, 2009 at 11:22 PM, Maciej Stachowiak m...@apple.com
wrote:
On Sep 28, 2009
+public-script-coord
-public-webapps
(Soon I will start dropping es-discuss too).
On Sep 29, 2009, at 3:38 AM, Yehuda Katz wrote:
I meant actually written. Being able to see actual code that
implemented pieces of the IDL in ES would make some of the more
complex interactions more obvious
On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:
Sorry... somehow Waldemar's comment got closed up in my Gmail
conversation stack and I missed this comment...
If Oliver and Hallvord and Brendan are wrong on the idea that it is
at least largely already a de facto standard for non-indexed
On Oct 14, 2009, at 10:47 PM, Maciej Stachowiak wrote:
(*) - If you use constructor functions to make an object with
properties named (x, y, z) added in that order, with a prototype
that has properties (a, b, c), and in turn has a prototype with
properties (q, r, s), JSC
On Oct 15, 2009, at 10:54 AM, Mike Shaver wrote:
On Thu, Oct 15, 2009 at 1:47 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Is the Mozilla document.all optimization contingent upon the
occurrence of the text document.all?
No, but it's contingent on the property lookup being
On Oct 15, 2009, at 10:23 AM, Allen Wirfs-Brock wrote:
I'm not particularly defending IE's legacy enumeration order, we
were initially on board with ES5 adopting the de facto order used by
other browsers. My recollection is that the decision to table
defining a strict enumeration order
On Nov 4, 2009, at 2:49 PM, Allen Wirfs-Brock wrote:
A straw man proposal for Harmony encapsulated hash codes has been
posted to the Wiki athttp://wiki.ecmascript.org/doku.php?id=strawman:encapsulated_hashcodes
1) Wouldn't it be simpler to have a single Object.hash() function that
On Nov 5, 2009, at 11:03 PM, David-Sarah Hopwood wrote:
Oliver Hunt wrote:
-- for instance in the DOM I cannot set indices of a NodeList, but
the
NodeList does not need to be frozen.
NodeList objects are read-only.
But the values they return may change over time due to factors other
On Nov 5, 2009, at 5:14 PM, Charles Jolley wrote:
I hadn't thought about freeze affecting all other values on the
object. I agree that is not desirable.
Still, having separate object types for mutable and immutable
objects introduces a new pattern to JS. Why not follow the pattern
minimal, at least for
starters.
Regards,
Maciej
On Nov 4, 2009, at 4:26 PM, Maciej Stachowiak wrote:
Many APIs being developed for the Web platform would benefit from a
good way to store binary data. It would be useful for this to be
specified as part of the ECMAScript language, but it's
On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:
On 6 Nov 2009, at 19:24, Brendan Eich wrote:
On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:
Just in case some of you weren't aware, the CommonJS group has
done quite a bit of work and (bikeshedding) on this topic. Here's
a link to the
On Nov 7, 2009, at 6:53 PM, Ash Berlin wrote:
On 8 Nov 2009, at 02:21, Maciej Stachowiak wrote:
On Nov 7, 2009, at 5:39 AM, Ash Berlin wrote:
On 6 Nov 2009, at 19:24, Brendan Eich wrote:
On Nov 6, 2009, at 10:44 AM, Dean Landolt wrote:
http://wiki.commonjs.org/wiki/Binary
[snip
On Nov 18, 2009, at 3:25 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote:
otherWindow.copyOfEvalFromYetAnotherWindow(...) throws
[...]
What is the rationale for throwing in this last case, rather than
using the explicit base object
On Dec 7, 2009, at 7:22 AM, Kevin Curtis wrote:
This covers the origin of the idea and some of it's uses:
https://mail.mozilla.org/pipermail/es-discuss/2009-May/009234.html
I'm interested in JsonML AST as a DSL target.
Hacking the YACC file in jsc to parse the ES5 grammar as expressed in
On Dec 7, 2009, at 10:11 AM, Brendan Eich wrote:
On Dec 7, 2009, at 8:56 AM, Maciej Stachowiak wrote:
Actually, this is potentially a factor for any natively supported
AST format. If execution is direct rather than via transoformation
to JS source, the implementation would have to verify
On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:
Static Array and String Generics was an ES4 proposal[0], and is
implemented in Mozilla JavaScript 1.6[1].
What are the plans for including Array and String Generics in future
revision of ES?
I'm curious about this as well. We've had some
1 - 100 of 125 matches
Mail list logo
