Re: [webkit-dev] JSObjectGetClass proposal

[Darin Adler]

> On Jul 22, 2016, at 6:16 AM, Danilo Cesar Lemes de Paula 
>  wrote:
> 
> 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).

There seems to be a misunderstanding here.

When using the JavaScriptCore C API, the creator of the class owns the private 
data and so if your library is creating the JSClassRef, it should also own the 
JSObjectSetPrivate pointer for the objects you create. You say that the data is 
“already taken”, but I do not understand what that means. What are you already 
using the private data for?

Having the creator of the class also determine the structure of the private 
data is the correct design pattern. I would not consider that leaking 
implementation details to the user.

If you think that users or your code will want their own private data on top of 
the data that your class needs, that is something that’s could be accommodated 
by adding an additional function that stores their private data function within 
your private data.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JSObjectGetClass proposal

[Danilo Cesar Lemes de Paula]

On 21-07-2016 18:28, Darin Adler wrote:
>> On Jul 21, 2016, at 12:09 PM, Danilo Cesar Lemes de Paula 
>>  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
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev