Seth Falcon wrote: > 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? >
This is not primarily a question about implementation but about what the user understands. IMO, a function should have an intuitive meaning to the user. Its name is taking up a "global" place in the user's brain, and good software design says not to overload users with too many arbitrary names to remember. To be a bit facetious, if "flag is a slot in class Bar, it's really not a good idea to define the accessor for that slot as flag <- function(object)[EMAIL PROTECTED] Nor is the situation much improved by having flag() be a generic, with the only method being for class Bar. We're absconding with a word that users might think has a general meaning. OK, if need be we will have different flag() functions in different packages that have _different_ intuitive interpretations, but it seems to me that we should try to avoid that problem when we can. OTOH, it's not such an imposition to have accessor functions with a syntax that includes the name of the slot in a standardized way: get_flag(object) (I don't have any special attachment to this convention, it's just there for an example) > >> 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. > See above. That's true _if_ the name or some other syntactic sugar makes it clear the this is indeed an accessor function, but not otherwise. > 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). > I agree that we must handle such ambiguities, but I doubt that many people will be able to reliably use that syntax interactively. A more plausible prospect is for the user interface to offer the option to disambiguate the name, as opposed to using the current "greedy" search for the name. Also, a variant of the with() notion might be helpful, so a whole expression could be bound to a particular package. But notice that the problem only arises when different packages have _different_ meanings for the same generic. Having a syntactic convention for accessors means in effect that an accessor for a slot of a particular name is conceptually one generic, no matter how many packages use it. This would not come free; my guess is we need an explicit mechanism for creating accessor methods, including a syntactic convention. For one thing, R will move more and more to functions, classes and methods with the corresponding package as part of the identification. That means that to regard accessors of one slot name for more than one package as methods for one generic, that generic must NOT belong to each individual package. I've experimented a bit with explicit accessor functions on a couple of occasions; if there's enough interest, we could start a discussion, perhaps in a separate list, of ways to go. > + seth > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
