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, [EMAIL PROTECTED] 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]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
