[webkit-dev] JSObjectGetClass proposal
Danilo Cesar Lemes de Paula
danilo.eu at gmail.com
Fri Jul 22 06:16:18 PDT 2016
On 21-07-2016 18:28, Darin Adler wrote:
>> On Jul 21, 2016, at 12:09 PM, Danilo Cesar Lemes de Paula <danilo.eu at gmail.com> wrote:
>>
>> How to create a JSObjectRef as the same type as another one.
>
> Just curious: Is that something you can do in JavaScript itself?
Actually, this is a bit reduced version of my problem. I don't have much
contact with javascript itself. Basically we're working in a binding
engine so the user can call whatever system API they want using JS. We
export those interfaces when the javascript user asks for them.
Basically that's what Seed (dead) and Gjs (alive with SpiderMonkey) do.
But it's mainly C/C++ stuff with some javascript shell.
I did spend some time trying to apply javascripts hacks to avoid nasty
hacks in native code, without luck for this very specific this case. My
best option until now was defining a specific property during object
creation containing another object with the private pointer set to the
JSClassRef itself (as the main object SetPrivate structure is already
taken). But it also can be the root of more problems, despite the fact
that leaking implementation details to the user (like WTF is this
"OMG_PLEASE_DONT_TOUCH_THIS" property in my object?) is never a good
call (even with k..DontEnum and k..ReadOnly, imho).
Another suggestion I got was to save a list of created objects
statically... which can be problematic when memory addresses starts to
be reused after GC.
So, the API I proposed fixes that king of issue.
I do understand that adding more API to something that was quiet and
stable for a while raises some warnings. But, please, consider that this
API is simple enough, consistent, and the same API is available and had
been proven useful to other javascript engines (yep, I'm talking about
spidermonkey with its huge API monster.)
So, I guess that's it. If you can spare some time to review my patch I
would appreciate.
Thanks
Danilo
>
> — Darin
>
More information about the webkit-dev
mailing list