[BioC] Re: documenting S4 classes/accessors/encapsulation

[Luke Tierney]

On Wed, Mar 27, 2002 at 02:14:18PM -0500, Jeff Gentry wrote:
> 
> 
> On Wed, 27 Mar 2002, Robert Gentleman wrote:
> >  I wasn't proposing that we have to use setXYZ and getXYZ,
> >   but folks from the Java community
> 
> I've always personally liked the setX/getX syntax - it makes it obvious
> what's being done even to someone who might not be completely boned up on
> the details of the particular language.  It does seem a bit verbose, as
> well as (along Byron's point) looking at page after page of code sometimes
> the eyes blur the s's and the g's - but for understandability's sake, the
> set/get syntax has always appealed to me.
> 

I would prefer to avoid using setFoo(x, y) in R. One reason is that it
obscures what is really happening even more than <- assignment already
does.  Compound assignment in R is quite different from assignment
in Java: In Java

	x.foo = bar

means "take the object referenced by x and destructively change it's
foo field to contain bar."  In R

	x$foo <- bar

means: "create a copy of the object in x that has it's foo component
replaced by bar and assign this copy to x in the local frame (which
may not be where the original x lived)".  In other words, except for
efficiency hacks x$foo <- bar means

	x <- "$<-"("foo", value = bar)

Another issue with setFoo is that to write it requires using
non-standard evaluation tricks--eval/substitute sorts of stuff.  That
sort of code is horrendously hard to get right, and I think we should
try to do less of it rather than more.

A final issue is that hiding assignments inside function calls further
complicates identifying what the variables in a function are and this
in turn compicates attempts at building a compiler.

One other historical point on automatically generated accessors:
Common Lisp did this for structures: every slot got a reader and a
writer.  The names for structure FOO with slot A would be FOO-A.  I
think they decided this was not such a great idea, and when CLOS came
around they decided to do it differently: when you declare a slot you
can specify whether you want a reader, a writer, or both, and you can
specify the names you want.  This allows you to indicate that certain
slots are indented to be read-only or private (doesn't enforce this
but suggests it if you adapt the approach that clients of the code
should only use a functional ADT).  On the other hand, Dylan went back
to generating readers and writers for everything, so who knows.  Name
spaces should help reduce conflicts if we do go down that road.

luke

-- 
Luke Tierney
University of Minnesota                      Phone:           612-625-7843
School of Statistics                         Fax:             612-624-8868
313 Ford Hall, 224 Church St. S.E.           email:      luke@stat.umn.edu
Minneapolis, MN 55455 USA                    WWW:  http://www.stat.umn.edu