On Tue, Jul 7, 2009 at 6:29 PM, Drew Wilson wrote:
> 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 Wo
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);
yield
On Tue, Jul 7, 2009 at 5:25 PM, Adam Barth 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 ENABLE(CHANNEL_MESSAGING)
JSValue JS
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 Wilson wrote:
> So it seems like we should never reference lexicalGlobalObject in our
> constructor/prototype creation code a
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)
:
DOMObject(JSEventExceptionConstructor::createStructure(exec->lexicalGlobalObject()-
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-
>lexicalGlobalObj
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()))
{
putDirect(exec->property
[+sam]
On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilson wrote:
> On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak 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 Worker
>> constructor itself
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak 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 cached.
> How
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 I
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 speakin
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 I steal it :)
Looking at the Workers code (since that happ
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 Wilson wrote:
> BTW, Adam
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
specs.
BTW, Adam - can you elaborate your specific concerns?
On Tue, 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().protot
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 wrote:
2009/6/23 Drew Wilson :
> On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth 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.
>>
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 constr
On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth 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 spec briefl
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 10:44 AM, Darin Adler 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
> constructors, as lo
On Tue, Jun 23, 2009 at 10:41 AM, Maciej Stachowiak 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 class sounds l
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).
Perh
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 i
On Mon, Jun 22, 2009 at 11:07 PM, Maciej Stachowiak 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 at all these c
On Jun 22, 2009, at 10:07 PM, Adam Barth wrote:
On Mon, Jun 22, 2009 at 9:58 PM, Peter Kasting
wrote:
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth
wrote:
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiak
wrote:
Your proposed alternative will have different behavior. It will
use the
lexi
On Mon, Jun 22, 2009 at 9:58 PM, Peter Kasting wrote:
> On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth wrote:
>> On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiak wrote:
>> > Your proposed alternative will have different behavior. It will use the
>> > lexical global object of the calling JavaScript
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth wrote:
> On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiak 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 asso
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiak 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. Almost everywhere
On Jun 22, 2009, at 5:54 PM, Drew Wilson wrote:
I notice that this is a fairly common idiom in the WebKit JS bindings:
1) Storing away a pointer to the JSDOMGlobalObject in the constructor
JSOptionConstructor::JSOptionConstructor(ExecState* exec,
JSDOMGlobalObject* globalObject)
: DOMOb
I notice that this is a fairly common idiom in the WebKit JS bindings:
1) Storing away a pointer to the JSDOMGlobalObject in the constructor
JSOptionConstructor::JSOptionConstructor(ExecState* exec, JSDOMGlobalObject*
globalObject)
:
DOMObject(JSOptionConstructor::createStructure(exec->lexical
31 matches
Mail list logo
