On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
But Array.of is not. Maybe Array.new is a good name.
Array.of is unambiguous with the current ES specification
Array.new is ok too, though -- no problem with a reserved identifier as a
property name.
On Nov 22, 2010, at 11:35 PM, Brendan Eich wrote:
On Nov 22, 2010, at 11:19 PM, Maciej Stachowiak wrote:
Probably we need to take our time and not rush into a meta-programming-here
syntax variant of for-in. I'll not propose anything better right now.
If the colon is less future
On Nov 21, 2010, at 7:05 PM, Brendan Eich wrote:
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
Consensus that we should have iterators.
For this, after all these years (JS1.7 added meta-programmable for-in in
2006), I'm grateful, although I wanted to add something your notes did
On Oct 14, 2010, at 2:54 PM, Brendan Eich wrote:
On Oct 14, 2010, at 11:15 AM, Brendan Eich wrote:
On Oct 14, 2010, at 11:09 AM, Brendan Eich wrote:
Fixing this is possible too, if I can take liberties:
script-if type=application/ecmascript;version=6
// new.js inline-exanded here
On Sep 6, 2010, at 6:01 PM, Brendan Eich wrote:
On Sep 6, 2010, at 4:01 PM, Jürg Lehni wrote:
I agree it's a good name, but how about Object.isIdentical? Wouldn't that
follow existing naming conventions more closely?
It would following the verg-object-noun-phrase convention, but we have
On Sep 6, 2010, at 5:14 AM, Chris Marrin wrote:
On Sep 5, 2010, at 7:19 AM, Mark S. Miller wrote:
At the last EcmaScript meeting, I proposed the const function notation
seen at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions.
Someone -- my apologies, I forget who --
On Sep 6, 2010, at 9:30 AM, Jeff Walden wrote:
On 09/05/2010 08:31 PM, Maciej Stachowiak wrote:
The strawman has a note where I suggested matching hashcode with
identity as the method name. If nothing else, the name length and lack of
hackerly abbreviation recommend it. Comments?
I
On Sep 5, 2010, at 7:40 AM, Mark S. Miller wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:egal
I have previously taken the position on this list that we should not add a
third equality construct to JavaScript. However, it is relevant to several
other strawmen that are likely to
On Sep 5, 2010, at 12:28 PM, Brendan Eich wrote:
On Sep 5, 2010, at 8:28 AM, Maciej Stachowiak wrote:
Other possibilities:
- Make Object.hashcode pair with === or == instead of Object.eq: formally
impossible, because neither is actually an equivalence relation. Less
formally, possible
On Sep 5, 2010, at 1:08 PM, Sam Ruby wrote:
On Sun, Sep 5, 2010 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote:
The eq name is freakishly short, which might up the odds of it not
colliding with existing user-level extensions to Object
http://api.jquery.com/eq/
I don't think this
On Sep 5, 2010, at 5:49 PM, Jürg Lehni wrote:
I would propose to name it Object.equals() as opposed to the unnecessary
short eq(), which does not seem right next to unnecessarily verbose function
names such as Object.getOwnPropertyDescriptor()
equals or equal would be ok by me. eq is in
On Jul 30, 2010, at 2:53 PM, Brendan Eich wrote:
On Jul 30, 2010, at 2:43 PM, felix wrote:
Of course this does not say what the syntax for a meta-programmable
iteration construct should be, but laziness suggests all is not
precisely on target.
so why not make it for each? for-each
On Jul 24, 2010, at 11:51 AM, Mark S. Miller wrote:
On Fri, Jul 23, 2010 at 10:37 AM, Oliver Hunt oli...@apple.com wrote:
On Jul 23, 2010, at 10:32 AM, Brendan Eich wrote:
On Jul 23, 2010, at 10:27 AM, Oliver Hunt wrote:
[Good point about LL(∞) snipped.]
* To give you an idea of
On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote:
On Jul 25, 2010, at 4:59 PM, Maciej Stachowiak wrote:
On Jul 25, 2010, at 11:36 AM, Brendan Eich wrote:
Let's not go in circles. I claim:
* The horses are long gone from the barn.
* The mistake is easy to overlook even for JS coders
On Jul 25, 2010, at 4:57 PM, Maciej Stachowiak wrote:
Perhaps the strawman page for shorter function syntax should list reasons for
rejecting other syntax options. I would be happy to document the reasons
against fn, fun, f and \, but I can't seem to remember my username and
password
On Jul 24, 2010, at 12:40 PM, Brendan Eich wrote:
On Jul 24, 2010, at 11:58 AM, Mark S. Miller wrote:
On Sat, Jul 24, 2010 at 9:21 AM, Kevin Curtis kevinc1...@gmail.com wrote:
[...]
Also, is anything proposed for rationalizing ASI in Harmony.
I would welcome ideas. I was sad when we
On Jul 2, 2010, at 3:17 PM, David Flanagan wrote:
Mark S. Miller wrote:
However, many objected to ephemeron as obscure
jargon. We have not yet settled the name we are giving this abstraction.
It is the language of GC implementors, and won't make sense to JS programmers.
I'll be happy
On Jul 2, 2010, at 7:45 PM, Mark S. Miller wrote:
On Fri, Jul 2, 2010 at 4:40 PM, Maciej Stachowiak m...@apple.com wrote:
I agree that EphemeronTable is too jargon-ish and may dissuade developers
from using it. I like Map better than Table as a suffix. Ephemeral is an
improvement
On Jun 30, 2010, at 9:09 PM, Brendan Eich wrote:
On Jun 30, 2010, at 7:37 PM, Mark S. Miller wrote:
And you're right that attribute-property-missing - undefined - false has
an effect here. If we had kept the ES3 negative names, we could have
defaulted to false and Erik (I think) would
On Apr 29, 2010, at 9:09 PM, Brendan Eich wrote:
On Apr 29, 2010, at 7:26 PM, Mark S. Miller wrote:
We can't keep going around on this. I'm all in favor of shorthand
for function, but TC39 virtually dropped lambda. Do we really need
to revive it (and return to label, and probably other
On Dec 23, 2009, at 10:07 PM, Douglas Crockford wrote:
'die Straße geht jemals jemals auf'.toUpperCase()
Chrome: DIE STRASSE GEHT JEMALS JEMALS AUF
Firefox: DIE STRAßE GEHT JEMALS JEMALS AUF
IE8: DIE STRAßE GEHT JEMALS JEMALS AUF
Opera: DIE STRAßE GEHT JEMALS JEMALS AUF
Safari: DIE
On Dec 12, 2009, at 11:08 AM, Mark S. Miller wrote:
On Sat, Dec 12, 2009 at 10:53 AM, Mike Samuel mikesam...@gmail.com
wrote:
On the interaction of Function.prototype.toString and function
proxies, one use case is code that tries to get at a function's name
as by doing
function nameOf(f) {
On Dec 10, 2009, at 10:06 PM, Mark S. Miller wrote:
On Thu, Dec 10, 2009 at 9:58 PM, Maciej Stachowiak m...@apple.com
wrote:
Object.prototype.hasOwnProperty.call(d, name)
I'm a little less confident of the latter than the former. However,
Google Code Search finds a number of hits
On Dec 10, 2009, at 5:09 PM, Mike Samuel wrote:
2009/12/10 Mark S. Miller erig...@google.com:
hasOwnProperty - cannot for non host objects
Incidentally, is Object.prototype.hasOwnProperty(myProxy)
O(myProxyHandler.keys().length) for proxies? This seems bad since a
for (in) loop that
On Dec 8, 2009, at 3:43 PM, Allen Wirfs-Brock wrote:
I believe that there are still IPR policy issues that need to be
worked through before any test suite development that is affiliated
with ECMA/T39 could accept contributions from organizations or
individuals who do not have an ECMA
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
1 - 100 of 125 matches
Mail list logo
