On Wed, Sep 30, 2009 at 8:08 AM, Laurent Gautier <lgaut...@gmail.com> wrote: > Nathaniel Smith wrote: >> 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." > > No what I mean is what are doing in the case of a function with a signature > like (foo.bar=1, foo_bar=2) ?
I know what you mean, I'm saying that if you're designing a system where that's a tricky question then IMHO you've already made the system too complex. For my approach (unconditional _ to . conversion) the answer is trivial: you use rcall, just like you use for any other function with an underscore. > I am precisely advocating the absence of guessing, and be "better safe than > sorry" I can't quite tell what you're advocating -- it seems to me that there are two options that do not involve guessing: -- no conversion -- unconditional conversion In both cases we just document "this python code corresponds to this R code. Always. It does not depend on the function called, the phase of the moon, or the price of tea in china". But you don't seem to really like either of these, and you don't like guessing, so I'm not sure what you do want :-). >> For my own use, I looked around, and couldn't find any functions that >> had _ arguments, and lots that had . arguments. > > Older R code did not have _ (because it used to be an invalid character for > regular symbol, as _ was an alias for "<-"). > More recent code have. For example, ggplot2 only has _ in paramter names. I know. But ggplot2 is still an oddity, even for new code -- the old technical limitation set the convention, and it's still followed by sensible coders. Not everyone is sensible, alas, but for a convenience API I'd rather handle 95% of case than 75%. >> 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). > > "correct in more cases than doing no (name) conversion" ??? Not sure what you're trying to imply with your triple-question-marks :-), but yes, that's what I meant. Because it's much more common to be calling a function that uses . than to be calling one that uses _. -- Nathaniel ------------------------------------------------------------------------------ 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
