R help - Nov 2012 - decorating API in R

How best to implement a decorator pattern in R? What I mean, why I ask:

A group of ncdf4 users is trying to make it easier (notably for ourselves :-) to
write correctly IOAPI-formatted netCDF. Since IOAPI

http://www.baronams.com/products/ioapi/

decorates netCDF, one obvious way to do a package=ioapi is to decorate the
netCDF API from package=ncdf4. E.g., to add a data variable (datavar) with the
additional IOAPI metadata, ioapi::ncvar_add(...) would call
ncdf4::ncvar_add(...), then (e.g.--not complete, strictly for illustration)

* create global attr=VAR-LIST if it does not already exist
* add properly-formatted variable name to VAR-LIST
* add properly-formatted attrs longname, units, var_desc to the datavar if they
do not already exist

I've spent most of my codelife in Java, where one can decorate as above
either

* @ compile-time: simple inheritance. Brittle longterm, but gets the job done
for now.

* @ run-time: real Decorator Pattern ? la the Gang of Four. Not much harder,
usually worth the investment, but not "the simplest thing that could
possibly work," either.

But, given my ignorance of the R object models and dependency management, before
I put much scarce time into researching this, I thought I'd ask the
community for suggestions, references, and especially examples for how to do
this in R, especially how to extend one R package with another.

TIA, Tom Roche <Tom_Roche at pobox.com>

On Fri, Nov 9, 2012 at 9:10 PM, Tom Roche <Tom_Roche at pobox.com>
wrote:
>
> How best to implement a decorator pattern in R? What I mean, why I ask:
>
> A group of ncdf4 users is trying to make it easier (notably for ourselves
:-) to write correctly IOAPI-formatted netCDF. Since IOAPI
>
> http://www.baronams.com/products/ioapi/
>
> decorates netCDF, one obvious way to do a package=ioapi is to decorate the
netCDF API from package=ncdf4. E.g., to add a data variable (datavar) with the
additional IOAPI metadata, ioapi::ncvar_add(...) would call
ncdf4::ncvar_add(...), then (e.g.--not complete, strictly for illustration)
 You can pretty much do exactly that. There's no reason why your
package can't have:

ncvar_add = function(x,y,datavar){
  ncdf4::ncvar_add(x,y,something with datavar, etc etc with the custom
ioapi stuff)
}

 ie, your ncvar_add plays with its args and then calls the ncvar_add
in ncdf4. The problems are then:

 * If a user loads both packages, then one function will mask the
other - you'll get a warning, and to use the masked one you have to do
packagename::ncvar_add(foo)

 * You may now confuse users. Normally with OO systems you could have
some signature that decided which of a method to call, but you are
going to end up having to superclass the ncdf object... maybe...
horrible...
> I've spent most of my codelife in Java, where one can decorate as above
either
>
> * @ compile-time: simple inheritance. Brittle longterm, but gets the job
done for now.
>
> * @ run-time: real Decorator Pattern ? la the Gang of Four. Not much
harder, usually worth the investment, but not "the simplest thing that
could possibly work," either.
>
> But, given my ignorance of the R object models and dependency management,
before I put much scarce time into researching this, I thought I'd ask the
community for suggestions, references, and especially examples for how to do
this in R, especially how to extend one R package with another.
 I'm not sure you can 'extend' an R package with another package -
you
certainly cant just define 'package foo extends package bar' in any
way and expect foo::anything to call bar::anything.

 The conventional thing for you to do would be to write a new package
that depends on ncdf4, has functions with unique names, and then calls
ncdf4 package functions to do the ncdf4 level things. Anything wrong
with that?


Barry