[Webkit-unassigned] [Bug 36420] JSC needs an API to allow custom objects to have aprivate GC-accessible properties
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Mar 20 20:19:08 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=36420
--- Comment #3 from Oliver Hunt <oliver at apple.com> 2010-03-20 20:19:08 PST ---
(In reply to comment #2)
> (From update of attachment 51238 [details])
> Comments given on IRC:
>
> Docs:
>
> the headerdoc could maybe explain the purpose of this
> i.e. that it's a way to hold on to JavaScript values in a way that is safe for
> GC
> I think probably in the set one would be the best place to explain the purpose
> also maybe add a note to JSValueProtect
> to make clear that if you want one JS object to keep another alive, you
> shouldn't use it, you should use a private property
> otherwise you may get uncollectable reference cycles
I'm not sure about adding references to the new API from actual API until the
new API has gone through review.
>
>
> Error cases:
>
> JSObjectSetPrivateProperty seems to fail silently if the argument is not a
> callback object
> maybe it should have a boolean return? or raise an exception?
i'll make it return bool as setPrivate does
> it looks like JSObjectGetPrivateProperty will return garbage when called on a
> non-API object
> I think it would make more sense to return undefined
It returns NULL
> Silent failure on delete seems ok
I'll return bool to be consistent with SetPrivateProperty
>
> Testing:
>
> you could try harder in the test case to avoid the possibility that a copy of
> aHeapRef remains on the stack
It does get blown from the stack -- i verified the test failed before i added
marking support :D
> I think you should test calling these on non-API objects in the test case
Done.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list