On Jan 15, 2006, at 2:11 PM, Alexander Traud wrote:
happy that these function pointers are not destroyed magically.
Yes, but several strings on the heap are something else than a function
pointer. Yes, a REALbasic function pointer could move but we have
concepts
like handles or similar for something like that. I see no reason why
the
*NAME of a parameter* is hold on the heap.
Not that I don't agree with you. Dynamic access evaluates the complete
signature to allow screening for overloaded methods, which can contain
optional parameters, contrary to RB's plugin API's. Plugin API's use
"Direct Access" entry points, which screen for the method name only.
Plugin API function pointers are persistent following lazily creation.
In Dynamic Access NAME and DEFAULT value, or OPTIONAL on the heap may
be essential, but this is based on a gut feeling only.
In true Dynamic Access, one would expect the function pointers to
become deallocated once the instance is destroyed. My guess is that RS
did not want to do this because some of us, including me, were crying
out loud if we couldn't create a persistent function pointer for the
life span of the plugin.
As you pointed out, calls to REALLoadObjectMethod will be limited in
nature and therefore the leaking is not critical, nor disastrous
because once the plugin dies, these pointers will die too. File a
feature request, instead of a bug report, against the absence of a
REALUnloadMethod, and I'll be happy to sign on.
Alfred
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|