On May 15, 2009, at 2:34 AM, kevin curtis wrote:
If a function is used instead of a lambda, do the the same - syntactic
or semantic - problems arise?
No, because yield in a function makes it a generator, whereas in the
lambda proposal extended to treat yield as return/break/continue are
On May 15, 2009, at 1:47 PM, Waldemar Horwat wrote:
Did you actually test this? Firefox 2 and up work the same.
js g = gen()
[object Generator]
js g.next()
1
js g.next()
2
js g.next()
typein:6: ReferenceError: alert is not defined
js alert=print
function print() {
[native code]
}
js g =
On May 14, 2009, at 5:42 PM, Mark S. Miller wrote:
On Thu, May 14, 2009 at 3:42 PM, Brendan Eich bren...@mozilla.com
wrote:
On May 14, 2009, at 2:50 PM, Mark S. Miller wrote:
If so, did you have a different way of reasoning about the
reasons today
why
finally might not run that I
On May 16, 2009, at 5:50 PM, David-Sarah Hopwood wrote:
But you are right that dataflow concurrency is probably not
sufficient on its own if we want to make Harmony a practical
concurrent language.
That is not a goal at this point, and TC39 wouldn't hold the H-
release for it.
Bear in
On May 16, 2009, at 9:29 PM, David-Sarah Hopwood wrote:
(Implementation complexity and performance are also important, but
personally I consider them to be lower priorities than safety and
expressiveness -- especially since safety often has a lower
performance
cost than many people believe.)
This may be breaking a butterfly on a wheel, but I am game if it
improves the state of the strawman proposals.
On May 15, 2009, at 7:16 PM, David-Sarah Hopwood wrote:
My point was that the example of 'yield (foo)' (that is, yield as a
prefix operator applied to the expression '(foo)') shows
On May 17, 2009, at 11:00 AM, Brendan Eich wrote:
Python differs from JS by having only assignment statements, not
assignment expressions, which simplifies the problem a bit, as the
grep output cited above shows.
Of course this makes trouble with automatic semicolon insertion,
unless
On May 17, 2009, at 11:00 AM, Brendan Eich wrote:
Bean-counting productions in a traditional bottom-up grammar is also
silly given how many are required for ES1-3. From the patch, notice
all the existing specialized NoIn/NoBF/NoNode variants in parser/
Grammar.y (NoBF = No Brace at Front
On May 17, 2009, at 12:43 PM, Mark S. Miller wrote:
On Sun, May 17, 2009 at 11:00 AM, Brendan Eich bren...@mozilla.com
wrote:
Analogous to direct vs. indirect eval in ES5 (15.1.2.1.1), there is
no
purely syntactic specification for what Neil proposes. A runtime
check is
required. So I
On May 17, 2009, at 5:05 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On May 17, 2009, at 12:43 PM, Mark S. Miller wrote:
On Sun, May 17, 2009 at 11:00 AM, Brendan Eich bren...@mozilla.com
wrote:
Analogous to direct vs. indirect eval in ES5 (15.1.2.1.1), there
is no
purely syntactic
On May 17, 2009, at 5:14 PM, David-Sarah Hopwood wrote:
Biju wrote:
[behaviour of wrappers] is weird...
Why cant we make objects for Number, String, Boolean, Date acts like
their native counter part?
That will be what an average web developer expecting.
And I dont think it will make existing
Waldemar gave feedback
http://wiki.ecmascript.org/doku.php?id=strawman:catchalls#feedback
Waldemar's main point is a good one, which caused me to be hostile to
catchalls for years:
Catchalls climb the meta ladder. Primitive actions such as checking
for the existence of a property when
On May 17, 2009, at 11:48 AM, Brendan Eich wrote:
On May 17, 2009, at 11:00 AM, Brendan Eich wrote:
Python differs from JS by having only assignment statements, not
assignment expressions, which simplifies the problem a bit, as the
grep output cited above shows.
Of course this makes
On May 18, 2009, at 2:25 AM, Igor Bukanov wrote:
The remedy for this is simple - the generator can be created using
explicit call like Generator(f, arg1, ... argN). This would turn any
function into a generator and would allow for runtime checks for eval.
You mean yield, not eval, right?
On May 18, 2009, at 11:53 AM, Neil Mix wrote:
But for this to be true, we would need to use the direct-eval
detection hack I mentioned previously.
On the plus side, this would allow for feature detection of
generator support, right? (Is there any other way to detect
generator support?)
On May 19, 2009, at 2:00 PM, David-Sarah Hopwood wrote:
*If* it is allowed, then it should be two. It would be very
surprising if
foo(a = b, c);
had two arguments (as it does), but the above expression with yield
had one.
But I agree that it may be better not to allow it.
Good; it was a
On May 19, 2009, at 2:08 PM, David-Sarah Hopwood wrote:
A more explicit alternative is to require some kind of decoration on
the
function definition, e.g. (just a straw man):
function generator foo() { ... }
Or just (we discussed this briefly last summer in Oslo):
generator foo() { ... }
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 May 21, 2009, at 10:41 AM, Brendan Eich wrote:
Clicking Stop then terminated the loop, and as with IE, the finally
ran, as
er, the finally did *not* run.
/be
javascript:alert(x)
confirmed by alerting 8 not 7.
___
es-discuss mailing list
On May 21, 2009, at 4:15 PM, Kris Kowal wrote:
Upon further reflection, I'm not sure that parse(program:String):AST
would serve the purpose of fast sandboxing. The intent of splitting
parse and execute is to reduce the cost of execution, so that modules
can be reused in many small sandboxes.
As Ash points out, there's no memory-safe way to implement obj.kill()
short of a full GC.
There is no way JS will lose memory safety, ever!
What's more, we shouldn't expose a gc() call. It would only be abused
over time. Even if it were used well at first for a given browser
engine (or
On May 22, 2009, at 1:05 PM, David Semeria wrote:
Swap out to disk - sorry I thought that was implicit
There's no disk on some devices. Anyway, that's up to the OS.
Advisory calls could help but we need some real examples, or better:
evidence from real apps, before inventing advice APIs
On May 22, 2009, at 1:27 PM, David Semeria wrote:
On Fri, 2009-05-22 at 11:46 -0700, Brendan Eich wrote:
As Ash points out, there's no memory-safe way to implement obj.kill()
short of a full GC.
There is no way JS will lose memory safety, ever!
Why can't the deleted object still exist
On May 22, 2009, at 1:53 PM, David Semeria wrote:
First, null is not a value in the sense of object value. An object
takes up arbitrary space associating property names with values.
You're possibly confusing reference and referent again.
That's very likely - I have only a very rudimentary
On May 22, 2009, at 2:06 PM, Brendan Eich wrote:
On May 22, 2009, at 1:53 PM, David Semeria wrote:
First, null is not a value in the sense of object value. An object
takes up arbitrary space associating property names with values.
You're possibly confusing reference and referent again
On May 22, 2009, at 2:54 PM, Michael Schurter wrote:
Essentially my fear is that the meaning of use strict becomes
ambiguous when future versions of ECMAScript are released (6 and
beyond).
The Web doesn't rev just because a new edition of the standard comes
out. If only we could use
On May 14, 2009, at 2:10 PM, Mark S. Miller wrote:
On Thu, May 14, 2009 at 1:22 PM, Brendan Eich bren...@mozilla.com
wrote:
On May 14, 2009, at 12:24 PM, Jason Orendorff wrote:
3. When a lambda yields, [...]
there may be other functions on the stack, in between. You can't
always statically
On May 28, 2009, at 11:48 AM, Jim Blandy wrote:
This is just a desugaring of some nested lets, but we still have
yield capturing many frames. If this doesn't work, lambda is really
useless.
Dave replied, but I wanted to join in agreeing on the following:
For what it's worth, speaking as
On Jun 1, 2009, at 1:47 PM, Allen Wirfs-Brock wrote:
Jeff Walden wrote:
0. Throughout this email any reference to a property descriptor
refers
to the specification type, not to the reification of one as exposed
by
Object.getOwnPropertyDescriptor or to the object taken as an
argument by
On Jun 3, 2009, at 11:12 AM, Oliver Hunt wrote:
1.) leading zeros are parsed as decimal numbers (octal seems like a
bug no matter what, per MarkM)
IE8 and V8's JSON implementation, and json2.js at json.org all
interpret 010, as octal (eg. 8), and 009 as 9
Those look like bugs ;-).
The
On Jun 10, 2009, at 8:48 AM, Allen Wirfs-Brock wrote:
I believe that support for ISO dates in ES5 is intended to provide a
standard interchange format for dates, not for providing a locale
customized format for human consumption. Since ISO 8601 apparently
doesn't provide an encoding for
On Jun 14, 2009, at 8:24 PM, John-David Dalton wrote:
I noticed that most Array methods perform [[HasProperty]] checks on
the index values.
Array#indexOf and Array#lastIndexOf do not. Firefox 3, Safari 4,
Chrome 2 all seem to check [[HasProperty]] for Array#indexOf and
lastIndexOf.
Is this an
For ES5, this is a tempest in a teapot.
We at Mozilla are trying to remove assignable __proto__ in a near-term
release, except in these two useful and (AFAIK) safe cases:
* A newborn with no other properties.
* A recent-born in the midst of initialization via evaluation of its
object
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
On Jun 17, 2009, at 9:54 PM, Allen Wirfs-Brock wrote:
I agree that it is problematic to spec. things related to extensions
that are not part of the spec. In this particular case I wouldn't
talk about __proto__ at all. What I would do is specify that the
value of an object's [[Prototype]]
On Jun 22, 2009, at 3:46 PM, kevin curtis wrote:
Alternatively, ecmascript in the tracemonkey, v8 and nitro generates
x86/ARM code. Maybe there could be a ecmascript subset which generates
fast machine code for algorithmic intensive code. ie ignores global
object and prototype and is maybe
On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:
I've been looking around on the web for reasons why decimal arithmetic
should be added to ES. The most extensive page I could find was
http://speleotrove.com/decimal/decifaq.html. If anyone know other
good sources of information
On Jun 23, 2009, at 10:03 AM, kevin curtis wrote:
The requirement of security and speed don't always coincide! The
subset/dialect idea is interesting.
It's two-edged.
Adding standard subsets leads to case-analysis explosion, a recipe for
bugs and reduction of interoperability.
How
On Jun 23, 2009, at 1:21 PM, kevin curtis wrote:
At some point we might have ESn remove
ancient cruft so the horizontal arrows might stop pointing rightward.
A strong +1 for doing this in ES6. IMO ES5 gives developers a strong
backward compatible cross browser foundation for the short/medium
On Jun 24, 2009, at 1:49 AM, Christian Plesner Hansen wrote:
I don't know, the user doesn't say why this inaccuracy is a problem.
It sounds like he's just generally unhappy that arithmetic is
approximate. Decimal is approximate too.
That's true at very extreme margins only! Decimal does not
On Jun 24, 2009, at 9:58 AM, Christian Plesner Hansen wrote:
I have concluded that it's too late to fix anything by adding
decimal.
It's clearly to late to change the number type from binary to
decimal. So we
are going to let library authors cater to users, and get TC39 out
of this
On Jun 24, 2009, at 11:38 AM, Mike Wilson wrote:
Jason Orendorff wrote:
Eeuuurgh. In that case, what David-Sarah said.
What did he say?
He said don't do that, to paraphrase. Full quote:
The 'with' can be in non-strict code, which is perfectly
adequate for implementing a
On Jun 24, 2009, at 12:08 PM, Christian Plesner Hansen wrote:
The second message in this thread, my first reply to your head-of-
thread
message, said:
Anyway, decimal is not being pushed into JS at this point. At the
last
face-to-face TC39 meeting, we changed direction to explore
On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:
We can only focus on what's next. Our covenants the
s/the/that/
proscribe certain features are few: no ES4-style namespaces (Common
Lisp packages), nor packages built on them.
I reviewed the Harmony announcement message:
https
On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:
On Jun 24, 2009, at 12:08 PM, Christian Plesner Hansen wrote:
I am just as unsure of how to read that. Does at this point mean
that it's off the table altogether for harmony or only that it's been
postponed until later in the process?
Why
On Jun 24, 2009, at 12:37 PM, Brendan Eich wrote:
So let's say ES6 is Harmony.
Last message from me on this topic today, I promise.
I wanted to encourage the use of Harmony for what's next, over
against ES6. The ES3.1 - ES5 experience, and of course many
software release renumbering
On Jun 28, 2009, at 1:24 PM, Mark S. Miller wrote:
I note that your symmetric suggestion avoids the problem of most
other symmetric overloading systems, like Cecil, of diffusion of
responsibility.
Diffusion sounds like a problem, a bad thing, but consider (I've
quoted this before) the
On Jun 29, 2009, at 11:55 AM, Mark S. Miller wrote:
On Mon, Jun 29, 2009 at 11:21 AM, Brendan Eich bren...@mozilla.com
wrote:
On Jun 28, 2009, at 1:24 PM, Mark S. Miller wrote:
I note that your symmetric suggestion avoids the problem of most
other symmetric overloading systems, like Cecil
On Jun 28, 2009, at 7:05 AM, Christian Plesner Hansen wrote:
I'd like to propose an alternative approach that avoids these
problems. You could call it symmetric operator overloading. When
executing the '+' operator in 'a + b' you do the following (ignoring
inheritance for now):
1: Look up
On Jun 30, 2009, at 10:35 AM, Allen Wirfs-Brock wrote:
Pulling back from Mark's and Brendan's programming language
metaphysics discussion (which I think is interesting and useful) I
just wanted to say that I find Christian's proposal quite
interesting. It feels like a natural fit to the
On Jun 30, 2009, at 1:04 PM, Mark S. Miller wrote:
On Mon, Jun 29, 2009 at 10:26 PM, Brendan Eich bren...@mozilla.com
wrote:
On Jun 29, 2009, at 11:55 AM, Mark S. Miller wrote:
Let's try a reductio ad absurdum.
This doesn't settle anything since there is no for all claim in
Chambers
On Jul 1, 2009, at 12:48 AM, Christian Plesner Hansen wrote:
(1) seems avoidable, though -- *assuming* it is not a phantom cost.
We have
to deal with the symmetric vs. encapsulated issue, though. But
notice that
Christian's proposal does not use this in the method bodies!
The really nice
On Jul 1, 2009, at 10:08 AM, Steve L. wrote:
Opera 9.64 (and other versions I've previously tested this issue
with) alerts A: 2, 4, 6, 8 and B: 0. Like you, this is my
interpretation of correct handling according to the spec. Opera
tends to follow the spec most closely for regex issues, in
On Jul 1, 2009, at 8:14 AM, Christian Plesner Hansen wrote:
This cuts both ways. A multimethod reifies that global (lexically
scoped,
rather) cache.
Sure, I'm not saying it's unique to my proposal. I mention it because
it's an important aspect to keep in mind when considering the cost of
On Jul 3, 2009, at 1:21 AM, Christian Plesner Hansen wrote:
Likewise, for user-defined function foo, foo.prototype is writable
-- but
not so for built-in constructor functions, and not so for classes
as sugar
(more below).
All JS code currently in existence is based on user-defined
On Jul 3, 2009, at 5:29 AM, Christian Plesner Hansen wrote:
This is the critical point. Do you want operator overloading to
extend to classic objects (that is, instances of user-defined
functions) or to be restricted to the values/classes/types subset?
That's not as much a technical discussion
On Jul 5, 2009, at 7:52 AM, Christian Plesner Hansen wrote:
Custom literals is a nasty problem. To work with decimal literals,
for instance, the compiler can't be allowed to interpret numeric
constants; that has to be delegated to the decimal library.
To clarify, we wouldn't make 123 or 3.14
On Jul 6, 2009, at 6:10 PM, Alex Russell wrote:
This point disturbs me. Making classes frozen solves no existing JS
programmer problems, introduces new restrictions with no mind paid
to the current (useful) patterns of WRT the prototype chain, and
introduces the need for a const that only
On Jul 27, 2009, at 2:56 AM, Tom Van Cutsem wrote:
Could you point me to a page that explains the rationale behind
distinguishing data properties from accessor properties? At first
sight, it appears you don't need both since accessor properties can
easily subsume data properties.
ES5 is
On Jul 31, 2009, at 1:18 PM, Jeff Watkins wrote:
Has there been any talk about adding Weak References to EcmaScript?
If so, forgive me, because I missed it.
Yes, there has been. Searching site:wiki.ecmascript.org weak
reference shows some hits. The current place to look is a stub:
On Aug 3, 2009, at 10:21 AM, Erik Arvidsson wrote:
Discussing whether we want to put setTimeout etc into ECMAScript?
There is a clearly a gap between ES and HTML5. How can we close the
gap? Execution model needs to be standardized.
See current WHATWG work:
On Nov 4, 2008, at 10:43 AM, David-Sarah Hopwood wrote:
The bug that Brendan and I were referring to was 61911:
https://bugzilla.mozilla.org/show_bug.cgi?id=61911
For reference so new readers don't have to look far back in the old
thread.
On FF3.0.3, a bit of testing reveals that
On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote:
There was a discussion of this ticket on Hacker News this morning
and we had this slight confusion on whether giving RegExp objects a
[[Call]] property is permitted by spec http://news.ycombinator.com/item?id=760529
. I thought it was, since
On Aug 21, 2009, at 8:11 PM, Juriy Zaytsev wrote:
If `boundArgs` is an array of arguments to bind, then I think you
should be able to do this via something like:
Function.prototype.bind.apply(targetFn, [thisArg].concat(boundArgs));
// or maybe:
boundArgs.unshift(thisArg);
On Sep 2, 2009, at 7:14 PM, David-Sarah Hopwood wrote:
You missed my point. Why do *new* abstractions need to have a
[[Class]]
other than Object? The fact that existing abstractions are defined
that
way is not a sufficiently good reason.
I'm not sure who missed what, but as I pointed out
On Sep 3, 2009, at 8:48 PM, Allen Wirfs-Brock wrote:
ES3, 15.3.5.2, says the prototype property of function instances is
enumerable.
ES5, 13.2 step 17, says the prototype property of function
instances is not enumerable.
ES5, 15.3.5.2 also says non-enumerable so at least it is internally
This sounds like a binary trade: follow Python and other precedent, or
help autocompletion tools. I don't buy it, but it is hard to argue on
these terms. Putting the comprehension expression on the right could
help, but JS is dynamic: do you really know the type of i in more
interesting
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 of the artificial standards body divide may
very well
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
This may be difficult for many reasons, but where the spec ends up
is less important to me (and if you make me choose either-or, I
prefer w3's RF to Ecma's RAND on first principles) than that we
have good collaboration without
On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
[much appreciated information snipped -- thanks!]
I really don't see how the review process and accountability could
be much more open for the development of Web IDL elsewhere, nor is
the burden on reviewers that large... it would simply be
On Sep 24, 2009, at 4:06 PM, Charles Jolley wrote:
I'm curious, why not just give anonymous functions a default name
like callee. Or perhaps have callee defined in a function scope
to represent the function? That seems to be exactly the same as the
above; it just makes it easier for
On Sep 25, 2009, at 4:14 AM, Fabian Jakobs wrote:
foo would leak into the global namespace due to implementation
bugs in
JScript http://yura.thinkweb2.com/named-function-expressions/.
Right now I
don't see a good solution for this in strict mode.
But strict mode is not supported in
Three distinct topics are being mixed up here:
1. Whether to use WebIDL or some unproposed alternative.
2. Whether to use catchall patterns in new WebIDL-defined interfaces.
3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C.
The straw man (0. Whether to remove catchall
On Sep 25, 2009, at 10:31 AM, Charles Jolley wrote:
But strict mode is not supported in current or downrev IE. So it is
imperative that Microsoft fix these old named function expression
name-binding bugs before, or at the same time as, script mode along
with all of ES5 are supported in a
On Sep 25, 2009, at 11:28 AM, Brendan Eich wrote:
function compile(...) {
eval(var f = function() { + compile_optimized_query(); + });
(Stray ; there in the + chain, oops.)
return f;
}
This can be avoided by putting the var f = outside the eval, if you
parenthesize the lambda
On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote:
On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich bren...@mozilla.com
wrote:
My positions are:
1. WebIDL, the bird in the hand (I agree with Sam: go invent
something
better, come back when you're done).
2. Don't keep perpetuating catchall
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 harmful for new
interfaces injunction. I agree
On Sep 25, 2009, at 2:24 PM, Charles Jolley wrote:
But we can hear feedback, esp. on this list, about hardship
adopting strict mode in early ES5 implementations. Mozilla's will
be done shortly, and it sounds like WebKit's is coming along
quickly too. Feedback based on two interoperable
On Sep 25, 2009, at 3:22 PM, David Flanagan wrote:
Charles Jolley wrote:
Has anyone considered providing a more explicit way of testing for
this? Maybe a constant that is defined somewhere.
Strict mode isn't a global on-or-off thing. Some functions can be
strict while others aren't. So
On Sep 25, 2009, at 3:35 PM, Brendan Eich wrote:
Otherwise, what you're testing for is something like is this code
currently running in strict mode or was this library loaded under
strict mode?
Thanks for wiping up after me. :-)
David kindly pointed out that what I suggested originally
On Sep 25, 2009, at 4:07 PM, Charles Jolley wrote:
I would think the most useful test would be is strict mode
available not am I currently strict since you can assume the
later from the former but not the reverse.
Not sure how you can assume the latter from the former:
if (! function() {
On Sep 25, 2009, at 4:22 PM, Charles Jolley wrote:
Not sure how you can assume the latter from the former:
if (! function() { use strict; return this; }()) {
use strict;
/* I'm an ES5 browser and DEFINITELY in strict mode now; doesn't
matter what came before me... */
}
Gotcha -- I
On Sep 25, 2009, at 4:57 PM, Maciej Stachowiak wrote:
On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote:
So if you are doing more ArrayLike interfaces, let's keep talking.
Don't let at least my catchalls-considered-harmful statements stop
progress on ArrayLikes.
Perhaps when catchalls
, split windows,
execution model, etc. -- that's what I've been saying on the main
thread since the first message, and what Sam's transcription of a
private message from me tried to say.
Still not sure what your point is,
/be
-- Yehuda
On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich bren
On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote:
On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich bren...@mozilla.com
wrote:
On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:
Another way to put my earlier concern
Sorry, what earlier concern? You are replying to my reply to Doug
Schepers
I did not single out Replaceable in my efforts to understand.
Sure, but it is certainly odd and I wanted to recount some of the
history, just so you'd know not to over-attend to it. ;-)
WebIDL comes from OMG IDL, much of the precedent is documented in
various online sites, CORBA books,
On Sep 25, 2009, at 11:43 PM, Yehuda Katz wrote:
Do we disagree that it is a worthy goal to have a specification that
can be understood without having to take a while? I certainly
understand the utility in using something with precedent like IDL (for
implementors). Perhaps the IDL version could
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 for
a new ES language extension.
I previously
On Sep 26, 2009, at 11:16 PM, Cameron McCormack wrote:
OK, that is indeed what I’m hearing from you guys. “Host objects may
implement these [internal] methods in any manner unless specified
otherwise” in ES3 doesn’t sound like it’s particularly discouraging of
the different behaviour that Web
On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:
There are methods, but I'm not optimistic that they will cause
property reflection to wither.
getItem/setItem/removeItem/key/clear methods, plus .length -- not a
balanced name-set stylistically, but usable to avoid collisions (my
key
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 allow [[Construct]] without
[[Call]], but not [[Call
On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:
See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but
note objections there, as well as some alternatives discussed in es-discuss@mozilla.org
.
Thanks for the reference. That does look similar to my suggestion.
However, it
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
DOMStringMap. If
that happened, I'm sure other browsers and the spec would
On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote:
On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:
But there's no point pretending the Web (ES, DOM, etc.) is an
example of a well-designed toolkit for building user-facing
distributed apps!
But we're not really free to discard
On Oct 10, 2009, at 1:09 PM, Brendan Eich wrote:
In either case shadowing must be handled. Implementations using the
snapshot each object while traversing once approach may see
different shadowing effects than implementations that snapshot the
whole chain up front and traverse again during
On Oct 11, 2009, at 12:23 PM, memo...@googlemail.com wrote:
Currently I do use such kind of prototypes:
person = new function(name) {
this.name = name;
}
person.prototype = new function() {
/* Private */
var id;
/* Public */
this.name = ;
this.age = 0;
this.location = US;
}
This
On Oct 11, 2009, at 1:28 PM, memo...@googlemail.com wrote:
Thanks for your answer.
This sketch could use a function-valued property of this to use the
private id member, for motivation.
Does your expression a function-valued property of this mean
method?
Sure, informally that's a method.
The issue is not overriding default for-in behavior (as you can do in
JS1.7 via __iterator__). The issue is the default behavior.
Waldemar's right, browsers differ on Array enumeration, for some or
all Arrays. My observation to TC39 when we last discussed this is that
most arrays are
On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:
Similarly, rather than trying to fully specifying for-in enumeration
order (and invariably causing potentially breaking changes for some
implementations)
I'm focusing on your parenthetical aside: we have precedent in Harmony
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
301 - 400 of 4618 matches
Mail list logo
