[datatable-help] setnames on a non-data.table object
Matt Dowle
mdowle at mdowle.plus.com
Wed Oct 2 16:13:09 CEST 2013
On 02/10/13 12:50, Ricky Saporta wrote:
>
> This might be a topic to raise in a separate email:
> What do you think of adapting a naming convention where the name of
> the function indicates when a function will modify an object by
> reference? In my personal work, I have been trying to end such
> functions with an underscore. Putting aside for the moment all
> obvious and not so obvious issues with changing the names of existing
> functions & backwards compatibility, is the idea itself worth
> considering?
Maybe. But the convention was already that any function started "set"
indicates it will change the object by reference. The documentation uses
"set*" in several places with this in mind.
> objects("package:data.table", pattern="^set")
[1] "set" "setattr" "setcolorder" "setkey" "setkeyv"
[6] "setnames"
>
If the functions insert() and delete() are added, they'll add and remove
rows by reference. Those verbs don't start with set, but it's clear (in
my mind) that they'd change the data.table by reference; e.g. insert(DT,
row number | "end", some data).
Looking at base etc for functions starting "set*" there's some
side-effect meaning intended there too (setwd, setTimeLimit, set.seed).
setdiff and setequal are about sets in the collection sense. So it's
just setNames as a one off really. And we don't use camelCase in
data.table, so that's how to remember that.
> objects("package:base", pattern="^set")
[1] "setdiff" "setequal" "setHook"
[4] "setNamespaceInfo" "set.seed" "setSessionTimeLimit"
[7] "setTimeLimit" "setwd"
> objects("package:stats", pattern="^set")
[1] "setNames"
> objects("package:utils", pattern="^set")
[1] "setBreakpoint" "setRepositories" "setTxtProgressBar"
Since other set* functions work on data.frame (set() for example!),
setnames should too. I was forgetting that. Let's change it then.
Matt
>
> Rick
>
>
>>
>> Matt
>>
>>
>> On 01/10/13 20:51, Ricardo Saporta wrote:
>>> Hi All,
>>>
>>> I'm wondering if there are any potential problems or unforseen
>>> pitfalls with having
>>>
>>> setnames(x, nms)
>>>
>>> call
>>> setattr(x, "names", nms)
>>>
>>> when x is not a data.table.
>>>
>>> Thoughts?
>>>
>>> Rick
>>>
>>> Ricardo Saporta
>>> Graduate Student, Data Analytics
>>> Rutgers University, New Jersey
>>> e: saporta at rutgers.edu <mailto:saporta at rutgers.edu>
>>>
>>>
>>>
>>> _______________________________________________
>>> datatable-help mailing list
>>> datatable-help at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/datatable-help/attachments/20131002/bde13585/attachment.html>
More information about the datatable-help
mailing list