[Rd] Name spaces and behavior of overloaded functions?

[Luke Tierney]

On Tue, 28 Jan 2003, Henrik Bengtsson wrote:

> First of all, I haven't followed the discussion about the new/upcoming
> name space support in R so I do not know the purposes or requirements
> for it, neither its design, and I can only guess. I found the (initial?)
> notes by Luke Tierney on the Developers Page. Are there any other
> references?

Not yet.

> Since it seems that the current implementation (R v1.6.2) of name spaces
> is a "trial" version and not really officially announced I though it
> would be better to ask my questions on this list:
> 
> hist() is internally creating an object of class 'histogram' and calling
> plot() on this object, which will (through the S3/UseMethod mechanism)
> call plot.histogram(). In pre Rv1.6.x I used to overload the
> plot.histogram() with my own backward compatible version, which added
> two arguments specifying the width and offset of the bars, making it
> easier to have two  or more histograms in the same plot.
> 
> However, I noticed that since R v1.6.x the hist() -> plot() ->
> plot.histogram() sequence is now restricted to hist() -> plot() ->
> base::plot.histogram() (not explicitly). Where ever I put my redefined
> plot.histogram() function, i.e. before the 'base' package in the
> search() path, including .GlobalEnv, it is ignored when calling hist().
> 
> Question 1: Is this due to the new name space support?

Yes

> Question 2: Is this the intendent behavior? 

Yes

> Question 3: If yes of Q2, then should plot.histogram() be considered a
> private function of the 'base' package?

No, it is public, but it is defined in 'base', as is 'hist'.

With any function call the search of the function begins at the
environment of the call site.  The first function found is used.  When
a call site is in a function defined in a name space (the call to plot
is in the function hist defined in 'base') and that name space
provides a definition of the function, then that definition is used.
The assumption is that the package authors knew what they were doing
when they created the two functions together.  Since S3 method
dispatch (simplified a bit) turns a call of plot(x) with
class(x)=="histogram" into a call of plot.histogram(x), it follows the
same rules.

If for functions in package 'base' you feel you have a definiiton that
is more suitable for you than the one provided then you can arrange
for your own version to be used but you have to work at it: you have
to explicitly assign your version into the 'base' environment.  This
may be made a bit more difficult in the future by locking bindings in
'base', but it will pobably always be possible at least for most
functions.

S3-style method dispatch is not a good fit with name spaces, and there
are scenarios where the current approach to dispatching could not find
any method even though one exists in a place that would seem
reasonable.  One way of dealing with this under consideration is to
provide an optional explicit method registration mechanism to augment
the existing dispatch process.  The current experimental
implementation checks for explicitly registered methods after doing
the usual search.  This was done to minimize changes from the current
setup.  But it may make sense to think about checking for explicit
registrations first.  This would allow you to use that mechanism to
register your plot.histogram method.  It is likely that by default
there will be at least a warning when attempting to replace an already
registered method.

Hope that helps.

luke

-- 
Luke Tierney
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
   Actuarial Science
241 Schaeffer Hall                  email:      luke@stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu