Ross Boylan wrote:
On Tue, 2005-06-07 at 08:36 +0200, Uwe Ligges wrote:
Ross Boylan wrote:
On Sat, Jun 04, 2005 at 07:08:56PM +0200, Martin Maechler wrote:
Ross> nextPath <- function(pm){ #pm is a CompletePathMaker
Ross> [EMAIL PROTECTED] <- [EMAIL PROTECTED](1)
Ross> [etc]
If your nextPath function has 'pm' as its last statement it
will return the updated object, and if you call it
as
mypm <- nextPath(mypm)
you are
1) updating mypm
2) in a proper S way (i.e. no cheating).
Regards,
Martin
Wow. This is almost the exact inverse of the usual object behavior,
in which only the class itself can update the slots (aka instance
variables). None of the methods of the class can update instances of
the class persistently without the help of outsiders, and only
outsiders can change the slot values.
(Yes, I realize that using the idiom you suggest of returning a new
object one can have only class methods actually fiddling with the
slots.)
The inability of a class method to change a class object without
outside help seems unfortunate.
It looks as if instances of class objects are best thought of as
immutable once created.
Obviously, there are many definition of "object oriented" programming,
and yours seems to be different from the S4 definition.
Yes. And though there are many definitions of "object oriented" (at
least, many implementations), I'd say the minimum requirement to be
object oriented is to have objects that encapsulate both state (instance
variables/slots) and behavior (methods).
S4 objects do not fully encapsulate state because they require outside
assistance to alter the state of the object (with the exception of
assignment operators). The smalltalker in me also gets nervous that
code outside the class can access the slots, but there are many object
systems that act that way.
The way in which names of methods of unrelated classes interfere with
each other seems a break-down of the encapsulation of behavior, though
the problem strictly is not with the behavior but just with the name.
To return to the concrete problem that got me started, if class
Specification defines a method likelihood taking as arguments instances
of class Specification, Path and Parameters, then it is awkward to
define a method likelihood for the class Model when that method has
arguments of class Model, Specification, data.frame, and vector,
particularly if different names for the formal arguments are desired.
(I think technically it could be done, but only in a very ugly
way--i.e., better to use different method names for the two classes).
I was going to answer your first question at first, but you have not
given enough details - in particular it was not clear to me why your
approach did not work.
I assumed that you are assigning the new object
again, which is the S way.
I wasn't, which is why it didn't work. I wanted the function to return
some other value than the object it was operating on.
You have to think about scoping rules and it
will be clear that the approach you are expecting is not a clean one in S.
Could you say a bit more about that?
I meant the following simple example (not related to any object oriented
programming from the S point of view, but maybe well from your point of
view?):
Say you want a function foo() that simply incements the argument:
a <- 1
foo(a)
a # now is 2
But what happens if there is (more than) one "a" (in different
environments), but no "a" in the environment foo(a) is called from.
Which "a" do you want to change in this case? Seems to be rather dangerous.
Uwe Ligges
I had thought of the issue more in
terms of function calls in S being call by value, preventing updates to
the original arguments. So the issue isn't so much the scope of the
names of function arguments (that scope being limited to the function
body), but the properties of the thing they refer to (conceptually, a
copy of the argument, not the original).
______________________________________________
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
______________________________________________
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
