[Rd] Objects in R

[Byron Ellis]

On Apr 23, 2005, at 11:54 PM, Duncan Murdoch wrote:

> Byron Ellis wrote:
>> On Apr 21, 2005, at 9:37 AM, Nathan Whitehouse wrote:
>>>
>>>
>>>   (1)Novices simply don't understand it.  Students are
>>> trained in "standard" object-oriented technique and
>>> this wonkish offshoot(puritanical functional
>>> programming) just increases the information costs to
>>> using R and thus decreases the demand.
>> The obvious solution here is to avoid the phrase "object oriented," 
>> since that apparently means "acts like Java" these days.
>
> That's actually a good suggestion.  In S4, objects don't own methods, 
> generics do, so it might be more informative to call it "generic 
> oriented".

People may confuse that with C++'s "generic programming," maybe "data 
oriented" programming or something ;-)

>> I'm not sure what your complaint about serialization is exactly, 
>> serialization is just a way of storing data---its not like Java 
>> serialization is actually putting *code* into data objects or 
>> anything, so S4's method of saving objects is more or less 
>> equivalent. Yes, you have to have the class definition around to get 
>> the object back in a reasonable way, but this is true of any 
>> language.
>> As for the visitor pattern, the need to implement the visitor pattern 
>> is actually a hack needed for single dispatch object systems to 
>> overcome that limitation (typically implementing some sort of double 
>> dispatch system). This is a classical example of why you really want 
>> S4's style of OO and NOT GangOfFour style OO not the other way 
>> 'round. You simply implement the methods directly with a signature of 
>> length 2 instead of a signature of length 1.
>
> I disagree with this.  Dispatch on multiple arguments is not 
> inconsistent with Java-style OOP.  It would be called "function 
> overloading".
>
> I don't know if there are languages that do this (i.e. do function 
> overloading based on run-time type, rather than declared type), but 
> that's likely because I don't know a lot of languages, not because 
> they don't exist.

Naw, it still doesn't work since you wouldn't able to extend an object 
you don't own to dispatch to new sorts of visitors. You can do a bit 
better by ignoring typing altogether a la Smalltalk leading to a much 
cleaner implementation of the visitor pattern, but its still not 
totally gone. Multimethods OTOH give you both the typing information 
and the class extension (since classes don't hold methods at all).

>
> The big advantage of Java-style OOP is that it allows a clear 
> definition of what is needed in order to be a valid descendant class.  
> For example, if I want to be a descendant of a "vector", I would need 
> to implement index lookup and assignment, a way to print when in a 
> data.frame, etc.
>
> With S4, it's not so clear what my class needs to do to be a vector. 
> Suppose I call my class myVector, and get it working, submitted to 
> CRAN, etc.
>
> Independently, you create a new generic that is supposed to work on 
> vectors.  You are unaware of my work, so you don't create a method for 
> MyVector, and I'm unaware of your work so I don't create one either. 
> When someone else tries to use both of our packages, they don't work 
> together.
>
> In Java-style OOP, on the other hand, you couldn't change the 
> requirements for MyVector.  If it did the things that were required by 
> the original class definition properly, then it would work with your 
> code (since you couldn't require anything beyond the original 
> definition).  If you needed methods not in the original, you would 
> have to declare a new class, and there wouldn't be a risk of a third 
> party getting burned by mixing my code with yours.

More precisely Java's Interface system allows for the clear definition 
of requirements for a particular type. Ironically this system exists 
outside of the Java's OO structure and plays be completely different 
rules (no inheritance, no polymorphism. encapsulation doesn't apply 
since interfaces can't hold mutable data. All they really give you is 
abstraction). I'd be more than happy to see S4 pick up some sort of 
protocol mechanism, but that can (and does in other languages) 
obviously exist independently of a Java-style OO system.

>> Abandoning OOP how? S4 is just as object oriented (more so) than S3 
>> and is certainly as object based as Java or C++. Sure it doesn't 
>> really act like the Java/C++ style of OO, but to paraphrase the 
>> famous  Alan Kay quote, "I coined the term object oriented and I sure 
>> wasn't thinking of C++ when I did."
>
> What S4 is missing is "encapsulation". Wikipedia's article on 
> object-oriented programming gives a good definition:
>
> "Encapsulation - Ensures that users of an object cannot change the 
> internal state of the object in unexpected ways; only the object's own 
> internal methods are allowed to access its state. Each object exposes 
> an interface that specifies how other objects may interact with it."
>
> Neither of these properties holds in S4.

They don't hold in C++ or Java either if the object has a public data 
member. Also, S4 classes already have this by convention--- foo() and 
foo()<- much in the same way Java has adopted the convention of 
getFoo() and setFoo() (or Smalltalk's foo foo: and so on). The only 
difference is that an R function doesn't know when its a method call so 
there's no good way of restricting the '@' operator to situations where 
you should have access to the data members.

I would also observe that the Wikipedia article also contains an entire 
section ("Multimethod Model") on S4's OO model.

>
> Duncan Murdoch
>
---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian