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