R-alpha: Re: What are objects?

Martin Maechler Martin Maechler <maechler@stat.math.ethz.ch>
Tue, 2 Sep 1997 09:48:05 +0200

[I do think
  this discussion belongs to  R-devel  rather than anywhere else .. MM]

>>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

>>>>> Peter Dalgaard BSA writes:

    >> Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:
    KH>>>  While trying to write documentation for data.class(), I came
    KH>>> across the following in the help for class():
    KH>>> An R ``object'' is a data object which has a `class' attribute.
    KH>>> ...  LANG(is.object) returns LANG(TRUE) if its argument has a class
    KH>>> attribute and LANG(FALSE) otherwise.
    KH>>> Hmm ... I thought everything was an ``object''.  What is the right
    KH>>> way to refer to ``everything'' then?

    PD>> I agree, this is silly. Did we pick that one up from S, or can we
    PD>> fix it?

    Kurt> I'd say that this is an R&R decision, but I don't think we picked
    Kurt> it up from S.  In S, everything is an object.  Also, S does not
    Kurt> have the R is.object() which in fact is only used once ...

    PD>> Obviously, it makes much more sense to let an entity with no class
    PD>> attribute be an object of the default class. And having to
    PD>> distinguish between "data objects" that are objects and those that
    PD>> aren't is - um - confusing.

    Kurt> Right.

    Kurt> What we might do is distinguish (in terminology) between objects
    Kurt> and ``proper objects'' which are the ones with a class.
or ``class objects''.
Yes I think it's good idea to agree on terminology here.

    Kurt> As (correct me if I am wrong) eventually everything will have a
    Kurt> class (as in S4) everything will eventually be a proper object,
    Kurt> and data.class will be unnecessary.
[I do correct ..]
Hmm, I think that Ross recently said
that  R is NOT moving into the  S4 direction (of fully OO), really,
but rather emphasizes speed and compilation possibilities
	[[unfortunately, I can't find that email in my archives, now...]]


    Kurt> Btw, would there be any problems in attaching corresponding class
    Kurt> attributes to at least

    Kurt> 	array matrix list

    Kurt> ???  (Martin, I need your strong YES PLEASE once more ...)  Would
    Kurt> this break anything?  The creator functions could simply attach
    Kurt> the attribs.

I actually have only voted for 'matrix' to be class
 (and 'Matrix' to be another class, inheriting from 'matrix' with just a
  different method for "[").
'array' would be ok, too (and one could think of 'Array' with the analogous
			  "[.Array" method as "[.Matrix")

I'm not so sure about the usefulness of a 'list' class.
Many objects are lists, internally anyway, and I want to access them as
lists sometimes, even if they have an(other) class.

Apropos 'matrix'  (an S / S-plus story) :
-------  ~~~~~~~
In the mean time, I've stumbled about this (again!) in S-plus:

returns a matrix with a class attribute 'matrix'
does NOT
which is really ugly.

I think the 'deep' reason for this is the following:
Current S3 based S-plus still contains code with
which I think is also known as "old S code".
Anyway, I know that functions using "old S code" are NOT allowed
to get arguments with class (or other "non-standard") attributes.

Therefore, in current S-plus, quite a few (more) things would break if all 
matrices were of class 'matrix'.
And this is probably the only reason why they don't have the class 'matrix'

    Kurt> (Does anyone know exactly what S4 does?)
	how do you mean this?
         probably only John Chambers could say 'yes' to this....

r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch