[Rd] S4 Dispatching

[Byron Ellis]

To answer my own question: Yes, it will explode. I was just getting  
lucky. Right, back to the drawing board :-)

On Jul 22, 2005, at 6:07 PM, Byron Ellis wrote:

> 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
>
> ______________________________________________
> 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