In fact there is a heuristic test that is cheap and reasonably 
reliable.  The class attribute generated for S4 objects itself has an 
attribute, "package".  A C-level test for the existence of that 
attribute is cheap enough, I would think, that most anti-S4 users 
wouldn't notice it in match(), c(), etc.  Of course, nothing prevents 
someone from putting a package attribute on an S3 class, but it seems 
unlikely.

This is _not_ the right solution, which most everyone agrees is to have 
an explicit SEXP.  But it should bridge the gap until someone with 
sufficient knowledge of R internals implements that solution.

There is one catch, but it doesn't seriously affect tests for match(), 
etc.  Two of the built-in S4 classes don't currently have a "package" 
attribute; it's just a slipup in the bootstrapping of S4 classes.  Easy 
to fix, but it means that the test won't work for code designed _for_ S4 
classes unless all packages are re-installed with the fixed version.  
For this reason, I haven't committed the change.

The catch is not a serious problem if the code in question was not meant 
to work for S4 objects in the first place: weird things will happen if 
someone applies match() to a class representation object, for example, 
which presumably no one would do just for the sake of generating an error.

I'll try to commit the new test sometime soon & if there are no serious 
problems,  we can start including it in some of the relevant functions.



Seth Falcon wrote:

>On  7 Feb 2006, maechler@stat.math.ethz.ch wrote:
>  
>
>>The solution has been agreed to be changing the internal
>>representation of S4 objects making them a new SEXP (basic R
>>"type"); and as Brian alludes to, the problem is that those in
>>R-core that want to and are able to do this didn't have the time
>>for that till now.
>>    
>>
>
>The explanations from you are Brian are helpful, thanks.  I was aware
>that the issue is the internal representation of S4 objects and was
>hoping there might be a cheap work around until a new SEXP comes
>around.
>
>It seems that S4 instances are less trivial to detect than one might
>expect before actually trying it.  
>
>I suppose one work around is to have an S4Basic class that defines
>methods for match(), c(), etc and raises an error.  Then extending
>this class gives you some protection.
>
>+ seth
>
>______________________________________________
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>  
>

	[[alternative HTML version deleted]]

