[Rd] Depreciating partial matching
simon.urbanek at r-project.org
Thu Mar 21 16:00:41 CET 2013
On Mar 21, 2013, at 10:48 AM, Terry Therneau wrote:
> 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.
If this is really true (that ESS doesn't complete in R files) then this seems more like a bug (or wish?) report for ESS - other editors correctly support code completion in R documents - after all this is a feature of R, so they don't need to re-invent the wheel.
>>> 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
> R-devel at r-project.org mailing list
More information about the R-devel