On Wed, Sep 30, 2009 at 10:05 AM, Nathaniel Smith <n...@pobox.com> wrote: > > On Wed, Sep 30, 2009 at 1:15 AM, Laurent Gautier <lgaut...@gmail.com> wrote: >> >> Rewriting function signatures in order to replace '.' with '_' is something >> that is ichting me, but which I would like to happen a safe way. For >> example, what if a function signature has both 'foo.bar' and 'foo_bar' in >> its list of parameters ? > > IMHO, if you're wondering about the case where *both* are valid, then > you've already lost. If you're wondering that, then it means you're > trying to handle the case where function A takes foo.bar, and function > B takes foo_bar, and you want to be able to call both A and B and have > the interface magically know how to munge the argument name for each. > But how can it possibly know in a reliable way? "In the face of > ambiguity, resist the temptation to guess." > > For my own use, I looked around, and couldn't find any functions that > had _ arguments, and lots that had . arguments. So I declared that _ > to . conversion is an unconditional part of the convenience wrapper > interface, comparable to data type conversion. (I also declared that > trailing underscores are stripped -- to make functions like 'class' > and 'print' accessible -- and the word 'dollar' becomes '$'.) These > rules are simple, predictable, correct in vastly more cases than doing > no conversion, and for the occasional weird edge-case you can still > use rcall just like now (only the weird edge-cases are much rarer). > > -- Nathaniel
This is like the simple "." to "_" mapping in rpy1, very simple and generally good enough. Simple rules are good :) And for the rare cases when this approach doesn't work, there are other options. Peter ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
