[Rd] S4 Dispatching

[Byron Ellis]

I'm not sure I understand here... If I do, say...

setClass("id","externalptr")

where classes of that type come back from, effectively, C functions  
that do something like

PROTECT(ret = NEW_OBJECT(MAKE_CLASS("id")));
R_SetExternalPtrAddr(ret,myid);
UNPROTECT(1);
return ret;

am I just asking for an explosion somewhere down the line? (I haven't  
noticed anything in particular so far...) I'm not adding any slots  
since it happens that all of the pointers of interest have  
information that should either a) live on the pointer side or b)  
lives in a meta object of some sort.



On Jul 22, 2005, at 5:39 AM, John Chambers wrote:

> That is definitely a problem in the current R implementation.
>
> Because external pointers (and environments and some other data types)
> are not duplicated in the way that ordinary vectors are, you cannot
> directly extend them as a class.  You can't for example set the  
> class of
> such an object without affecting all the other code that uses the same
> pointer.
>
> The usual workaround is to define a list of one element that contains
> the external pointer, and make that the object.  Or equivalently  
> set up
> an S4 class with the external pointer as a slot.  That's not a really
> satisfactory workaround, though, since it's not what was intended.
>
> It would be nice if the implementation duplicated the attributes, if
> any, of such objects.  But that appears not to be a simple fix--- 
> trying
> out that change causes problems that seem to be related to garbage
> collection or other internals of storage management.  A change for the
> future perhaps ...
>
>
>
>>
>> Thanks for your patience and help.
>>
>> ----------------------------------------------------------
>> SIGSIG -- signature too long (core dumped)
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian