This:
2) There's not currently a performance penalty for re-checking the
property name in the catchall getter that you currently have available,
because it gets called without JavaScriptCore doing a property lookup first.
Pretty much changes everything for me. Now it's just code I have to
On Fri, Jul 24, 2009 at 10:07 AM, Darin Adlerda...@apple.com wrote:
On Jul 23, 2009, at 5:56 PM, Eric Seidel wrote:
It sounds like you agree with me, that the Document should have a way to
get to the JSDOMGlobalObject w/o having to go through the Frame. Am I
understanding correctly?
Yes,
Ok. I've filed:
https://bugs.webkit.org/show_bug.cgi?id=27640 -- about DOMWindow::document()
https://bugs.webkit.org/show_bug.cgi?id=27662 -- about document-globalObject()
For now I will reference those bugs in the places where the binding
code needs those calls.
On Fri, Jul 24, 2009 at 10:07
Hi folks.
The WebKit project assumes the LP64 approach to 64-bit. Roughly
speaking, that means that:
- int is a signed 32-bit integer
- unsigned is an unsigned 32-bit integer
- long long is a signed 64-bit integer
- unsigned long long is an unsigned 64-bit integer
And long
On Fri, Jul 24, 2009 at 12:46 PM, Darin Adler da...@apple.com wrote:
Some of our code uses types like int32_t, uint32_t, int64_t, and uint64_t.
I don’t see the point of doing this. I’d like to suggest that we always use
int where we’d otherwise use int32_t except where there is some issue of
On Jul 24, 2009, at 11:05 AM, Adam Barth wrote:
Do you have specific areas you're concerned about that we can be on
the lookout for?
I tried to think this through, but only had a few minutes free:
A minor concern is that Frame has a constellation of helper classes to
help keep it simple,
Thanks. This is very helpful.
On Fri, Jul 24, 2009 at 1:18 PM, Darin Adlerda...@apple.com wrote:
On Jul 24, 2009, at 11:05 AM, Adam Barth wrote:
Do you have specific areas you're concerned about that we can be on the
lookout for?
I tried to think this through, but only had a few minutes
Am I missing something? Is there some real benefit to using types
like int32_t instead of int in some places in our code and not
others? If so, what are these critical places and what makes them
different from the rest of the code?
In JavaScriptCore, some structures have integer members
so maybe it doesn't matter assumes on Intel?
Would the observation change on, say, ARM?
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org]
On Behalf Of Geoffrey Garen [gga...@apple.com]
Sent: Friday, July 24, 2009 2:27 PM
To:
In JavaScriptCore, some structures have integer members that must be
32bits in size, regardless of processor type. In those places, int32_t
and uint32_t are useful.
Less clear to me is whether clients of such structures should also use
int32_t / uint32_t. For example:
struct {
int32_t i;
10 matches
Mail list logo
