On Mar 1, 2013, at 8:03 AM, Matthew Dowle wrote: > > Simon Urbanek wrote : >> Can you elaborate on the details as of where this will be a problem? Packages >> should not be affected since they should be importing the namespaces from the >> packages they use, so the only problem would be in a package that uses both >> data.table and rJava -- and this is easily resolved in the namespace of such >> package. So there is no technical reason why you can't have multiple >> definitions of J - that's what namespaces are for. > > Right. It's users using J() in their own code, iiuc. rJava's manual says "J is > the high-level access to Java." When they use J() on its own they probably > want the rJava one, but if data.table is higher they get that one. > They don't want to have to write out rJava::J(...). > > It is not just rJava but package XLConnect, too. If there's a better way would > be interested but I didn't mind removing J from data.table. >
For packages there is really no issue - if something breaks in XTConnect then the authors are probably importing the wrong function in their namespace (I still didn't see a reproducible example, though). The only difference is for interactive use so not having conflicting J() [if possible] would be actually useful there, since J() in rJava is primarily intended for interactive use. Cheers, Simon > Bunny/Matt, > > To add to Steve's reply here's some background. This is well documented in > NEWS > and Googling "data.table J rJava" and similar returns useful links to NEWS and > datatable-help (so you shouldn't have needed to post to r-devel). > > From 1.8.2 (Jul 2012) : > > o The J() alias is now deprecated outside DT[...], but will still work inside > DT[...], as in DT[J(...)]. > J() is conflicting with function J() in package XLConnect (#1747) > and rJava (#2045). For data.table to change is easier, with some efficiency > advantages too. The next version of data.table will issue a warning from J() > when used outside DT[...]. The version after will remove it. Only then will > the conflict with rJava and XLConnect be resolved. > Please use data.table() directly instead of J(), outside DT[...]. > > From 1.8.4 (Nov 2012) : > > o J() now issues a warning (when used *outside* DT[...]) that using it > outside DT[...] is deprecated. See item below in v1.8.2. > Use data.table() directly instead of J(), outside DT[...]. Or, define > an alias yourself. J() will continue to work *inside* DT[...] as documented. > > From 1.8.7 (soon to be on CRAN) : > > o The J() alias is now removed *outside* DT[...], but will still work inside > DT[...]; > i.e., DT[J(...)] is fine. As warned in v1.8.2 (see below in this file) and > deprecated > with warning() in v1.8.6. This resolves the conflict with function J() in > package > XLConnect (#1747) and rJava (#2045). > Please use data.table() directly instead of J(), outside DT[...]. > > Matthew > > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel