John Chambers <[EMAIL PROTECTED]> writes: > There is a point that needs to be remembered in discussions of > accessor functions (and more generally). > > We're working with a class/method mechanism in a _functional_ > language. Simple analogies made from class-based languages such as > Java are not always good guides. > > In the example below, "a function foo that only operates on that > class" is not usually a meaningful concept in R.
If foo is a generic and the only method defined is for class Bar, then the statement seems meaningful enough? > Functions are first-class objects and in principle every function > should have a "function", a purpose. Methods implement that purpose > for particular combinations of arguments. > > Accessor functions are therefore a bit anomalous. How? A given accessor function has the purpose of returning the expected data "contained" in an instance. It provides an abstract interface that decouples the structure of the class from the data it needs to provide to users. The anomaly, is IMO, a much larger challenge with generic function based systems. When the same name for a generic is used in different packages, you end up with a masking problem. This scenario is unavoidable in general, but particularly likely, for accessors. As S4 becomes more prevalent, I suspect that '<pkg>::foo' is going to become a required idiom for interactive use (other options are available for package code). + seth ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
