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:The obvious solution here is to avoid the phrase "object oriented," since that apparently means "acts like Java" these days.
(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.
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 ([EMAIL PROTECTED]) "Oook" -- The Librarian
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
