At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and Noon
on Friday has been suggested for this.
To help prime the pump, here are four topics suggested by ECMA TC39 for
discussion. On these and other topics,
On Thu, 24 Sep 2009 14:36:56 +0200, Sam Ruby ru...@intertwingly.net
wrote:
The current WebIDL binding to ECMAScript is based on ES3... this needs
to more closely track to the evolution of ES, in particular it needs to
be updated to ES5 w.r.t the Meta Object Protocol.
Is there a more
Sam Ruby wrote:
A concern specific to HTML5 uses WebIDL in a way that precludes
implementation of these objects in ECMAScript (i.e., they can only be
implemented as host objects), and an explicit goal of ECMA TC39 has been
to reduce such. Ideally ECMA TC39 and the W3C HTML WG would jointly
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 be
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 of the
I'll think about it. I was mostly hoping to start a discussion about
alternatives. I think the bottom line here is that while the spec is
well-optimized for implementors, it is not very well optimized for
consumers. I suppose it would be possible to say that this stuff is *only*
for implementors.
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: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
Maciej Stachowiak wrote:
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.
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
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
Hi everyone.
Sam Ruby:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
I'm travelling at the moment, so apologies for the delay in replying.
Unfortunately I
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 arcane and very implementor-specific. Consider:
interface UndoManager {
readonly attribute unsigned long length;
getter any
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);
23 matches
Mail list logo
