[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>>>
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>>>
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...]]
Ross?
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:
There,
as.matrix.dataframe
returns a matrix with a class attribute 'matrix'
but
as.matrix.default
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
.S(...)
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'
everywhere.
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-