[Rd] S4 Dispatching
jmc at R-project.org
Fri Jul 22 14:39:36 CEST 2005
Paul Roebuck wrote:
> On Wed, 20 Jul 2005, John Chambers wrote:
>>Paul Roebuck wrote:
>>>Is it possible for S4 to (continue) dispatch to a class
>>>created during dispatching? The code below doesn't work;
>>>is this not possible or have I ommitted something?
>>"doesn't work"? This is not helpful. Please show what you got and what
>>you expected. The result below is what I would expect (& get) from your
>>List of 1
>> $ name: chr "mydata"
>> - attr(*, "class")= chr "mydata"
>>Since you used an undefined class "mydata" you can't expect very much
>>else to work with these objects. You did not in fact "create" the
>>class, you just assigned a class attribute to an object corresponding to
>>an undefined class. There is a warning message to that effect from the
>>second setMethod() call.
> In retrospect, that should have been expressed as "doesn't
> work as I expected". I was using 'options(warn=2)' and didn't
> notice the warning conversion. I expected evaluation of the
> class existence would occur when callGeneric() was invoked,
> not during setMethod(). Also surprised at the return to
> generic prior to the final dispatch (instead of going
> straight there) along that same line of thought.
> While it's true that all I did was add a class attribute to
> the object, I thought that was all that was required for a
> trivial S3 class to be "defined". In my case, it is solely
> for internal usage as an intermediate data object that
> allows R to handle its memory management. Not sure how to
> define an S4 class representation for an external pointer.
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
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)
More information about the R-devel