Re: [Rd] S4 setClass with prototypes " issues" (PR#8053)

From: John Chambers <jmc_at_r-project.org>
Date: Fri 05 Aug 2005 - 19:06:55 GMT

Well, let's say R is currently picky when only a prototype is supplied.

The following is either a workaround or a revised, fussier requirement for the example mentioned, depending on your interpretation.

R> setClass("sequence", representation(.Data="numeric"), prototype=numeric(3))
[1] "sequence"
R> xx <- new('sequence',c(1,51,10))
R> xx
An object of class “sequence”
[1] 1 51 10
R> is(xx, "numeric")
[1] FALSE So far, so good. But there are a couple of catches.

The resolution of prototype and representation is currently somewhat of a mess in the R implementation. There's been some discussion of cleaning it up, hopefully moving ahead from the Green Book description to a more coherent definition. So whether eventually one could (or should) omit the representation() part remains to be seen.

The other relevant flaw currently is that S4 objects have no special internal representation in R, so there's effectively no way to keep primitive operations from working on them. (The general & notorious example is that xx[] always returns something on an S4 object, even when it shouldn't.) In the current case, the problem is that, in spite of not extending "numeric", low-level arithmetic is still done.

R> xx+1
An object of class “sequence”
[1] 2 52 11

Something basic is needed here, in the code for primitives, but so far objections re efficiency have prevented doing anything.

Meanwhile, those more interested in getting something done than discussing, would need to implement explicit methods for the new class that either re-interpret or block the primitives that shouldn't happen in the standard way.

gunter.berton@gene.com wrote:

> To R-Developers:
>
> I wish to report what I believe are inconsistencies between Green Book
> descriptions and R methods behaviors. I **realize** that R does not
> guarantee total consistency with the Green Book; therefore I leave it to you
> to decide whether any of this is a bug, design choice, or a need for
> additional documentation -- or whether I have simply misread or overlooked
> existing explanations. If the latter, I apologize for the error, but it was
> not for a want of effort.
>
> The issues all revolve around the setClass('xxx',prototype=...) without any
> slots construction. All references are to the Green Book. R 2.1.1 (on
> Windows)
>
> 1. Classes so defined (with protype, no slots) are not instantiated as
> described on the bottom of p.289. In particular, the following example from
> the book fails:
>
>

>>setClass('sequence',prototype=numeric(3))

>
> [1] "sequence"
>
>>new('sequence',c(1,51,10))

>
> Error in initialize(value, ...) : cannot use object of class "numeric" in
> new(): class "sequence" does not extend that class
>
> 2. I have been unable to find any Help documentation about the proper method
> to instantiate classes defined by prototypes without slots. Experimentation
> showed that only one of the two approaches on the bottom of p.289 worked:
>
>
>>setClass('foo',prototype=numeric())

>
> [1] "foo"
>
>>z<-new('foo')

>
> ## new() works as it should
>
>>z

>
> An object of class "foo"
> numeric(0)
>
> ## But now try this ...
>
>>z<-1:3
>>is(z,'numeric')

>
> [1] TRUE
> ## Hence, if R followed the book's statement that "For this to work,
> 'object' must either be suitable as a prototype for 'myClass or belong to a
> class that can be coerced to 'myClass.'" (Note, I interpret this to mean
> that either of these conditions are sufficient for either of the approaches
> shown).
>
>
>>as(z,'foo')

>
> Error in as(z, "foo") : no method or default for coercing "integer" to "foo"
>
> ## But
>
>>class(z)<-'foo'
>>z

>
> An object of class "foo"
> [1] 1 2 3
>
> I was unable to find documentation for this behavior in R, assuming that
> this is not a bug. If it's a bug, it should be fixed, of course; if not, I
> think the behavior should be documented, perhaps in setClass.
>
> 3. Finally, and most disconcertingly, The Green Book says (p.288):
>
> "... We do NOT want a 'sequence' object to be interpreted as a numeric
> vector ... Doing arbitrary arithmetic on the object, for example would be
> disastrous...
>
> The use of prototypes without representations allows the class designer to
> limit the legal computations on objects made up of numeric data..."
>
> As I read this, this should mean that the following should fail, but it
> doesn't (continuing the above example):
>
>
>>z+1

>
> An object of class "foo"
> [1] 2 3 4
>
> Again, if this is not a bug, I think that this lack of adherence to the
> Green book should be documented in R. May I say, however, that I wish R had
> implemented the book's prescription.
>
>
> -- Bert Gunter
> Genentech Non-Clinical Statistics
> South San Francisco, CA
>
> "The business of the statistician is to catalyze the scientific learning
> process." - George E. P. Box
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat Aug 06 05:10:37 2005

This archive was generated by hypermail 2.1.8 : Mon 24 Oct 2005 - 22:27:37 GMT