On Jul 24, 2009, at 7:23 AM, Brian Barnes wrote:
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
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
Sure!
Geoff
On Jul 20, 2009, at 3:51 PM, Brian Barnes wrote:
What should be my next step, here? Submit a bug for this?
[] Brian
On Jul 20, 2009, at 6:05 PM, Geoffrey Garen wrote:
How about separate call backs at the class level? That would
solve my problem with minimal code movement.
Jumping in late here, but a couple of points:
1) Instead of JSClassSetPropertyGetterSetter, it might be more in line
with the class design to be able to define getters and setters in the
class struct, just as functions are. In addition to being more
convenient, this API may also provide
I was getting ready to try the first move from SpiderMonkey to Nitro,
and ran into a large problem. Right now, all my getters and setters are
at the property level. In the documentation I have, Nitro only seems to
put them at the object level. This would force a huge refactoring of my
code
Hi Brian.
I don't understand the distinction you're drawing between the
property level and the object level. Can you explain what those
mean and give an example of each?
Thanks,
Geoff
On Jul 20, 2009, at 9:14 AM, Brian Barnes wrote:
I was getting ready to try the first move from
In SpiderMonkey, you can create an object, and that object has a
callback to a getter or a setter in C. You get the name, look it up,
return or set a value. Nitro has that same functionality.
On SpiderMonkey, though, when creating a property, you can also do this:
Hi Brian.
I see what you mean now.
In JavaScriptCore, there's no API for defining C getters and setters
individually. There's an API for associating a set of C getters and
setters with a class, and there's an API for defining a generic
fallback getter and setter for a class.
I looked
I'm not sure you get exactly what I'm saying as you put class in places
where I'd expect property. For instance:
I looked briefly, and it seems like it would be relatively easy to add
an API for adding C getters and setters to a class individually. So,
that seems like a reasonable feature
On Jul 20, 2009, at 11:48 AM, Brian Barnes wrote:
I'm not sure you get exactly what I'm saying as you put class in
places where I'd expect property. For instance:
I looked briefly, and it seems like it would be relatively easy to
add an API for adding C getters and setters to a class
I'm not sure you get exactly what I'm saying as you put class in
places where I'd expect property. For instance:
I looked briefly, and it seems like it would be relatively easy to
add an API for adding C getters and setters to a class individually.
So, that seems like a reasonable
How about separate call backs at the class level? That would solve my
problem with minimal code movement. Something like:
JSClassSetPropertyGetterSetter(ctx,class,red,myRedGetter,myRedSetter);
Would that be more within the design?
BTW, thanks for listening and leading me through some
How about separate call backs at the class level? That would solve
my problem with minimal code movement. Something like:
JSClassSetPropertyGetterSetter
(ctx,class,red,myRedGetter,myRedSetter);
Would that be more within the design?
Yes. That's what I had in mind when I mentioned an API
What should be my next step, here? Submit a bug for this?
[] Brian
On Jul 20, 2009, at 6:05 PM, Geoffrey Garen wrote:
How about separate call backs at the class level? That would solve
my problem with minimal code movement. Something like:
JSClassSetPropertyGetterSetter
14 matches
Mail list logo
