yes, it was mostly in general. eg X <- 1:5 setnames(X, LETTERS[X]) # Error in setnames(X, LETTERS[X]) : x is not a data.table or data.frame
Ricardo Saporta Graduate Student, Data Analytics Rutgers University, New Jersey e: [email protected] On Wed, Oct 2, 2013 at 12:28 PM, Matt Dowle <[email protected]> wrote: > > Rick, > > Oh - setnames already does work on data.frame. That was a change in > v1.8.4. > > Was the question more for lists and vectors then (anything that can have > names), rather than just data.frame/data.table? > > Matt > > > On 02/10/13 15:13, Matt Dowle wrote: > > 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: [email protected] > > > > _______________________________________________ > datatable-help mailing > [email protected]https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help > > > > > > _______________________________________________ > datatable-help mailing > [email protected]https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help > > >
_______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
