one more point about accessors. when autogenerated in the OOP package, last time I looked, the accessor functions had a prefix for slot foo, you would get an accessor function "getFoo" you might also get an assignment helper "setFoo" we MAY want to start distinguishing our accessors in this manner. this can be done in a backwards compatible way, by simply adding compliantly named slots. we then deprecate the old style accessors and after a certain time, eliminate them from the class definition.

This always seemed sort of strange to me--we've already got foo() and foo()<- as a perfectly good get/set mechanism. I would even argue that this has a better visual representation than set and get since you are forced to look for a lowercase 'set' or 'get' in commands that are otherwise identical. There *is* a problem of complex set commands, but I've come to think that small objects might be the solution (instead of taking a single object type the ()<- takes some particular object type --a coercion of sorts) Byron Ellis (bellis@hsph.harvard.edu) "Oook" - The Librarian Please finger bellis@hsph.harvard.edu for PGP keys On Wed, 27 Mar 2002, Vincent Carey 525-2265 wrote: > one more point about accessors. when autogenerated in the > OOP package, last time I looked, the accessor functions > had a prefix > > for slot foo, you would get an accessor function "getFoo" > > you might also get an assignment helper "setFoo" > > we MAY want to start distinguishing our accessors in this manner. > this can be done in a backwards compatible way, by simply > adding compliantly named slots. we then deprecate the > old style accessors and after a certain time, eliminate them > from the class definition. > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > http://www.stat.math.ethz.ch/mailman/listinfo/bioconductor >

On Wed, Mar 27, 2002 at 01:57:13PM -0500, Byron Ellis wrote: > This always seemed sort of strange to me--we've already got foo() and > foo()<- as a perfectly good get/set mechanism. I would even argue that > this has a better visual representation than set and get since you are > forced to look for a lowercase 'set' or 'get' in commands that are > otherwise identical. There *is* a problem of complex set commands, but > I've come to think that small objects might be the solution (instead of > taking a single object type the ()<- takes some particular object type--a > coercion of sorts) I wasn't proposing that we have to use setXYZ and getXYZ, but folks from the Java community kinda like it that way. If it makes it easier for them then that is fine. There is a syntactic issue in the new regime since one uses a call to setReplaceMethod("foo"...), and gets back a foo<- object. This is a bit of a disconnect but probably not that important. r > > > Byron Ellis (bellis@hsph.harvard.edu) > "Oook" - The Librarian > > Please finger bellis@hsph.harvard.edu for PGP keys > > On Wed, 27 Mar 2002, Vincent Carey 525-2265 wrote: > > > one more point about accessors. when autogenerated in the > > OOP package, last time I looked, the accessor functions > > had a prefix > > > > for slot foo, you would get an accessor function "getFoo" > > > > you might also get an assignment helper "setFoo" > > > > we MAY want to start distinguishing our accessors in this manner. > > this can be done in a backwards compatible way, by simply > > adding compliantly named slots. we then deprecate the > > old style accessors and after a certain time, eliminate them > > from the class definition. > > > > _______________________________________________ > > Bioconductor mailing list > > Bioconductor@stat.math.ethz.ch > > http://www.stat.math.ethz.ch/mailman/listinfo/bioconductor > > > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > http://www.stat.math.ethz.ch/mailman/listinfo/bioconductor -- +--------------------------------------------------------------------- ------+ | Robert Gentleman phone : (617) 632-5250 | | Associate Professor fax: (617) 632-2444 | | Department of Biostatistics office: M1B28 | Harvard School of Public Health email: rgentlem@jimmy.dfci.harvard.edu | +--------------------------------------------------------------------- ------+

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