Seth Falcon wrote:
> John Chambers <jmc@r-project.org> 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)object@flag

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]]


