OK, coming back around to this - I'm looking at the automatically generated
constructors. As an example, let's look at something simple like
EventException.
JSEventExceptionConstructor(ExecState* exec)
:
I think it's quite likely that all the constructors are wrong. If
you're in doubt, you can test Firefox and IE to see how they behave.
On Tue, Jul 7, 2009 at 4:45 PM, Drew Wilsonatwil...@google.com wrote:
So it seems like we should never reference lexicalGlobalObject in our
On Tue, Jul 7, 2009 at 5:25 PM, Adam Barth aba...@webkit.org wrote:
I'd have to look at the code a bit more to know whether this is
correct. Where does |globalObject| come from?
It comes from the JSDOMWindow object where that constructor is exposed. Case
in point:
#if
Interesting - I ran some tests on both current WebKit and Firefox.
Firefox has a couple of interesting properties. For example this code:
Worker.prototype.foo = 3;
log(Worker.prototype.foo = + Worker.prototype.foo);
var worker = new Worker(foobar.js);
log(worker.foo = + worker.foo);
yields:
I had another question - I'm looking at JSWorkerConstructor code, but this
pattern exists elsewhere as well:
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
:
DOMObject(JSWorkerConstructor::createStructure(exec-lexicalGlobalObject()-objectPrototype()))
{
On Jul 2, 2009, at 10:12 PM, Drew Wilson wrote:
I had another question - I'm looking at JSWorkerConstructor code,
but this pattern exists elsewhere as well:
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
: DOMObject(JSWorkerConstructor::createStructure(exec-
On Jun 22, 2009, at 10:07 PM, Adam Barth wrote:
On Mon, Jun 22, 2009 at 9:58 PM, Peter Kastingpkast...@google.com
wrote:
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth aba...@webkit.org
wrote:
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiakm...@apple.com
wrote:
Your proposed alternative
On Mon, Jun 22, 2009 at 11:07 PM, Maciej Stachowiakm...@apple.com wrote:
I suspect most JS bindings in WebKit use the original more complicated
pattern Drew cited, instead of the more succinct but incorrect one.
There are some bugs on file about this. I've been meaning to go
through and look
On Jun 22, 2009, at 11:58 PM, Adam Barth wrote:
That's possible. I don't have a good idea of what it costs to
provide. The benefit is it makes it easier to write correct bindings
code. (Or maybe it makes it harder because you have more contexts to
choose from and choosing the right context
On Jun 23, 2009, at 10:41 AM, Maciej Stachowiak wrote:
On Jun 22, 2009, at 11:58 PM, Adam Barth wrote:
I don't really know how to solve this problem except by writing
tests. However, tests don't really help when introducing new kinds
of objects (e.g., workers, database transactions).
On Tue, Jun 23, 2009 at 10:41 AM, Maciej Stachowiakm...@apple.com wrote:
On Jun 22, 2009, at 11:58 PM, Adam Barth wrote:
It would be great to make it easier to write DOM constructors correctly.
Perhaps documenting the pattern and/or introducing a common base class will
work.
A common base
On Tue, Jun 23, 2009 at 10:44 AM, Darin Adlerda...@apple.com wrote:
Perhaps it's possible to write a test that both checks which global object
is used for every constructor, and checks that the test covers all
constructors at the same time. Maybe there is a practical way to iterate the
On Jun 23, 2009, at 11:50 AM, Adam Barth wrote:
Is there a good way to tell if something is a constructor versus a
function?
Leading capital letter may be a good rule to start with. I don't think
we have plans to add functions that start with a capital letter or
constructors that do not.
On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote:
I am not even sure all of these should have the same behavior,
however. For instance, as I read the Web Workers spec, the lexical global
object may be correct thing to use for the Worker constructor.
I looked at the
Following up after an IRC chat with Ian - for Workers it is his intention to
always grab the context from the currently executing script, not from the
window the constructor originated from.
So for Workers, using the more succinct implementation is actually correct -
in his words all Worker
2009/6/23 Drew Wilson atwil...@google.com:
On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth aba...@webkit.org wrote:
I am not even sure all of these should have the same behavior,
however. For instance, as I read the Web Workers spec, the lexical global
object may be correct thing to use for
Not sure. There's language in the WebIDL spec around prototype objects of
interface objects, but I'm not sure how window.Worker.prototype is intended
to relate to
new Worker().prototype (if at all), based on my 10 minutes of scanning specs.
-atw
On Tue, Jun 23, 2009 at 3:26 PM, Adam Barth
BTW, Adam - can you elaborate your specific concerns?
On Tue, Jun 23, 2009 at 3:37 PM, Drew Wilson atwil...@google.com wrote:
Not sure. There's language in the WebIDL spec around prototype objects of
interface objects, but I'm not sure how window.Worker.prototype is intended
to relate to
new
On Jun 23, 2009, at 3:37 PM, Drew Wilson wrote:
Not sure. There's language in the WebIDL spec around prototype
objects of interface objects, but I'm not sure how
window.Worker.prototype is intended to relate to new
Worker().prototype (if at all), based on my 10 minutes of scanning
I don't mean to pick on workers specifically. We have lots of bugs in
the bindings where we attach the __proto__ property of new objects to
the wrong prototype chain. My specific concern is that we should fix
these bugs. :)
Adam
On Tue, Jun 23, 2009 at 3:38 PM, Drew Wilsonatwil...@google.com
On Jun 23, 2009, at 3:44 PM, Adam Barth wrote:
I don't mean to pick on workers specifically. We have lots of bugs in
the bindings where we attach the __proto__ property of new objects to
the wrong prototype chain. My specific concern is that we should fix
these bugs. :)
Tentatively
On Jun 23, 2009, at 4:08 PM, Drew Wilson wrote:
Oh, certainly - I just started looking at the Worker constructor
code, so I definitely have no sense of ownership there, so pick
away. I was just trying to understand the issues well enough to
understand what the Worker code is doing before
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com wrote:
The code above means that Worker.prototype is set at the time the Worker
constructor itself is created, which is good. In the line you bolded, a fresh
prototype object is created, and under the covers it will get
[+sam]
On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilsonatwil...@google.com wrote:
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak m...@apple.com wrote:
Also, there might be a subtle bug in the above code: what if window.Worker
is first accessed from a different frame? Then the prototype of the
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiakm...@apple.com wrote:
Your proposed alternative will have different behavior. It will use the
lexical global object of the calling JavaScript function, instead of the
global object originally associated with the Options constructor.
Yes.
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiakm...@apple.com wrote:
Your proposed alternative will have different behavior. It will use the
lexical global object of the calling JavaScript function, instead of the
On Mon, Jun 22, 2009 at 9:58 PM, Peter Kastingpkast...@google.com wrote:
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiakm...@apple.com wrote:
Your proposed alternative will have different behavior. It will use the
27 matches
Mail list logo
