Skip to content

Name spaces and behavior of overloaded functions?

2 messages · Henrik Bengtsson, Luke Tierney

Original
Henrik Bengtsson
# 
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?

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?

Question 2: Is this the intendent behavior? 

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

Of course it works if I use h <- hist(..., plot=FALSE) and call plot(h,
...) explicitly. However, I am not really interested in a workaround for
this specific problem, but more in how name spaces are going to change R
and if there is a well defined plan/specification at the moment.

Best wishes

Henrik Bengtsson

Home: 201/445 Royal Parade, 3052 Parkville
Office: Bioinformatics, WEHI, Parkville
+61 (0)412 269 734 (cell), +61 (0)3 9345 2324 (lab),
+1 (508) 464 6644 (global fax)
hb@maths.lth.se, http://www.maths.lth.se/~hb/
Time zone: +11h UTC (Sweden +1h UTC, Calif. -8h UTC)
1 day later
Luke Tierney
#
On Tue, 28 Jan 2003, Henrik Bengtsson wrote:

            

      
      
      
    

        
Not yet.

            

      
      
      
    

        
Yes

            

      
      
      
    

        
Yes

            

      
      
      
    

        
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