[Rd] Depreciating partial matching
therneau at mayo.edu
Thu Mar 21 15:48:39 CET 2013
Note: My apolgies for the "Subject" in the original post
On 03/21/2013 08:59 AM, Milan Bouchet-Valat wrote:
> Le jeudi 21 mars 2013 à 08:51 -0500, Terry Therneau a écrit :
>> I am not in favor of the change, which is a choice of rigor over usability.
>> When I am developing code or functions I agree with this, and I view any warnings from R
>> CMD check about shortened arguments as positive feedback.
>> But 90% of my usage of R is day to day data analysis, interactive, at the keyboard. A lot
>> of data sets that come to me have long variable names. What this change will mean to me
>> is that I'll either spend a lot of time cursing at these annoying frickin warnings, or
>> have to take the time to make new data sets (several times a week) that have abbreviated
>> names. Of course when I come back to that project 8 weeks later I'll need to recreate the
>> short-long mapping in my head...
>> Let's think about WHY abbreviated names were allowed in the first place. Usability is
>> worth a lot more than purity to the actual users of a package. S had the rare advantage
>> of serious users just down the hall from the developers, which I hypothesise is one of the
>> true foundation for it's success. (What user would have invented the hiding aspect S4
>> classes --- "let's put the results of the fit into a steel box so they can't see the
>> parts" --- which is actually touted as a virtue? I cringe every time a new method I need
>> is sewed up this way.)
>> "C is a remarkable language. ... The success of C is due to a number of factors, none of
>> them key, but all of them important. Perhaps the most significant of all is that C was
>> developed by real practioners of programming and was designed for practical day-to-day
>> use, not for show or for demonstration. Like any well-designed tool, it falls easily to
>> the hand and feels good to use. Instead of providing constraints, checks and rigorous
>> boundaries, it concentrates on providing you with power and on not getting in your way."
>> Preface to "The C Book", M Banahan et al
> I would think that the ability to hit the Tab key to trigger name
> completion in your R GUI makes partial matching almost useless. The
> avantage of interactive completion in the GUI is that you immediately
> see the result of the partial matching. So you get the best of both
> worlds: no need to type long variable names in full, but no traps when a
> match is not what you would expect.
> Doesn't this suit your use case?
Good point. This works well at the command line. However, not when interacting between
emacs and R in the way I do. For reproducability I use and emacs file that is being
corrected and massaged with chunks submitted to R; at the end I have a clean record of how
the result was obtained.
>> Terry Therneau
>> On 03/21/2013 06:00 AM, r-devel-request at r-project.org wrote:
>>> Allowing partial matching on $-extraction has always been a source of accidents.
>>> Recently, someone who shall remain nameless tried names(mydata)<- "d^2" followed by
>>> mydata$d^2. As variables in a data frame are generally considered similar to variables
>>> in, say, the global environment, it seems strange that foo$bar can give you the content
>>> of foo$bartender. In R-devel (i.e., *not* R-3.0.0 beta, but 3.1.0-to-be) partial matches
>>> now gives a warning. Of course, it is inevitable that lazy programmers will have been
>>> using code like
>> [[alternative HTML version deleted]]
>> R-devel at r-project.org mailing list
More information about the R-devel