://www.nabble.com/arguments.callee-in-Harmony-tp25603357p25610255.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
View this message in context:
http://www.nabble.com/arguments.callee-in-Harmony-tp25603357p25610255.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive
at Nabble.com
: arguments.callee in Harmony
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
to be added?
Thanks,
-Charles
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
View this message in context:
http://www.nabble.com/arguments.callee-in-Harmony-tp25603357p25610255.html
Sent from
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 of
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 implementations in developers'
hands before the ES5
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
ClassB = ClassA.extend({
foo: function method() {
(IS_ES5_STRICT ? method : arguments.callee).base.apply(this,
arguments);
}
});
But why wouldn't you use method always? Or callee, as Ollie
suggested. Agree it's annoying to have to add six letters of cruft
after the function keyword
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 you can't capture it in a constant.
Anyway, that's
On Sep 25, 2009, at 6: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: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
Brendan Eich wrote:
SC.HAS_STRICT = (function() {
use strict;
return !(function() { return this; }());
}());
(Or something like that. I sure will be happy when there's an
implementation to test this stuff against.)
You don't need two levels of functions. I just spaced out on the use
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
These are certainly idioms, especially the first test (as in kick
the bucket, something an ES3 programmer could not understand based
on the terms in the code alone, only by also reading the ES5 spec or
a book based on it). Do they deserve sugar?
To me this would be something that should be
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() {
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... */
}
___
es-discuss mailing
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 Fri, Sep 25, 2009 at 4:24 PM, Charles Jolley char...@sproutit.com wrote:
But just to be clear, after all of the discussion here, it appears that the
only way to implement a call super pattern in ES5 (without resorting to
closures as Breton suggested) would be to use the following magic
On Fri, Sep 25, 2009 at 2:24 PM, Charles Jolley char...@sproutit.com wrote:
PS. Is there an official way to detect that I am running code in ES5 strict
mode? I can't find it in the spec.
To summarize:
A conventional pattern for testing Am I in = ES5 strict mode? is
if (function(){return
Given your example, a named function expression would do the job
trivially:
ClassB = ClassA.extend({
foo: function foo() {
foo.base.apply(this, arguments); // calls super!
// other code
}
});
This works but, as I said, this approach has a couple of drawbacks:
1. The function
On Sep 24, 2009, at 3:55 PM, Charles Jolley wrote:
Given your example, a named function expression would do the job
trivially:
ClassB = ClassA.extend({
foo: function foo() {
foo.base.apply(this, arguments); // calls super!
// other code
}
});
This works but, as I said, this
In general I think this particular approach is not developer
friendly enough.
The function expression name is fairly irrelevant, so you could have
a standard style guideline
foo : function callee() {
callee.base.apply ...
}
This is actually a really interesting idea. I'll try to use
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
What I'd like to know is what the rationale for removing arguments.callee
from strict mode is. Is it a performance problem? If so, have implementors
tried other solutions at compile-time before agitating for the removal of a
language feature?
The argument that this is simply a strict mode change
On Fri, Sep 25, 2009 at 9:26 AM, Brendan Eich bren...@mozilla.com wrote:
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
x
On Fri, Sep 25, 2009 at 9:31 AM, Yehuda Katz wyc...@gmail.com wrote:
What I'd like to know is what the rationale for removing arguments.callee
from strict mode is. Is it a performance problem? If so, have implementors
tried other solutions at compile-time before agitating for the removal of
My general concern about strict mode is that it seems to be the result of a
smoke-filled-room compromise. I'd like to see the perspective of JavaScript
practitioners consulted about the strict mode definition (especially if it's
going to form the basis for ES Harmony).
-- Yehuda
On Thu, Sep 24,
On Fri, Sep 25, 2009 at 10:49 AM, Breton Slivka z...@zenpsycho.com wrote:
x
On Fri, Sep 25, 2009 at 9:31 AM, Yehuda Katz wyc...@gmail.com wrote:
What I'd like to know is what the rationale for removing arguments.callee
from strict mode is. Is it a performance problem? If so, have
Thanks for the pointer. It seems like the argument against it is security:
if I pass you my arguments object, you now have access to the original
function, which violates the POLA.
Isn't the fact (pointed out by Allen in the original thread) that
arguments.callee can be deleted a mitigating factor
The use of named function expressions is not correctly implemented by
at least IE 6-8.
The basic use case works fine (e.g.)
var foo = function callee() {
// do something
setTimeout(callee, 10);
};
But declared as
(function callee() {
// do something
setTimeout(callee, 10);
30 matches
Mail list logo
