[Rd] Limitations of generic functions

[Tim Keitt]

I think the issue is not whether C++/R OO models are better. R serves a
different role in computing than does C++. In my experience, simply
projecting (cloning) a C++ interface directly into R rarely provides
satisfactory results. Figure out what you want to do in R. Encapsulate
the appropriate abstractions using S4 methods and then figure out which
services you want to hand off to the C++ libraries. The low-level
manipulation of R's internal data structures can then be done in C++ in
your extension. Emulating C++ code in R is not much fun.

Ciao,
THK

PS. Sorry for the foo bar quoting. I'm subscribed to the digest. -- T.

> Message: 26
> Date: Thu, 21 Apr 2005 09:44:34 +0000
> From: "Ali -" <saveez at hotmail.com>
> Subject: [Rd] Limitations of generic functions
> To: r-devel at stat.math.ethz.ch
> Message-ID: <BAY17-F197A50240015116B894904D12C0 at phx.gbl>
> Content-Type: text/plain; format=flowed
> 
> (1) Assume we have some automatic C++ wrapper which , briefly, reads
> the C++ 
> files and generates some R files in which the equivalent of the C++
> classes 
> are reconstructed.
> 
> (2) As the OO design of R is different to that of C++, some isses
> exist when 
> creating an interface between these two systems. (I said these two
> are 
> 'different', I didn't say which one is better or which one is uglier.
> So 
> please save the posts on criticising the designs for somewhere else. I
> am 
> trying to make these two designs talk to each other without judging
> them.)
> 
> (3) One of these issues is about handling overloaded member functions
> in C++ 
> in the form of R classes. Following the discussion followed by my
> previous 
> post, I have decided to wrap the C++ in the form of S4 classes.
> 
> (4) Some more assumptions:
> 
>     (a) A C++ class may have any arbitrary number of overloaded
> functions 
> each of them have some arbitrary number of arguments.
> 
>     (b) To create the equivalent 'overloaded functions' in R, we need
> to 
> have a generic function with several methods. The arguments
> (signature) of 
> each of these methods are determined by the generic function.
>     (c) In order to make the automatic wrapper as general as possible,
> it 
> should not know about the arguments of the overloaded functions.
> 
> (5) And finally the question: How to define the generic function so
> that it 
> covers any unknown arguments of its methods? Apparently simply using
> '...' 
> does not work.

-- 
Tim Keitt
Section of Integrative Biology
http://www.keittlab.org/