as.Date.timeDate

[Gabor Grothendieck]

On Tue, Oct 18, 2011 at 12:18 PM, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> Gabor Grothendieck <ggrothendieck at gmail.com>
>>>>>>     on Tue, 18 Oct 2011 10:03:11 -0400 writes:
>
>    > While the change is caused by the second generic in zoo
>    > (which was necessitated by a change in R), note that the
>    > de facto standard set by the base package is to export all
>    > as.Date methods.
>
> that's not a "standard" but rather a kludge or
> a "historical coincidence" / an accidental reference to the past
> or ....
> as far as I see it...
>
> Really this should be discussed on R-devel, Gabor.
>
>    >   As we see, none of these methods are asterisked:
>
>    >> methods(as.Date)
>    > [1] as.Date.character as.Date.date      as.Date.dates     as.Date.default
>    > [5] as.Date.factor    as.Date.numeric   as.Date.POSIXct   as.Date.POSIXlt
>
>    > If timeDate follows the same standard then there will be no problem.
>
> Well, that's rather a *NON*-standard.
> The only reason I can think of currently that
> "base R" does not properly hide these is because they were
> already (mis)used in other CRAN packages.
>
> But I don't see why timeDate should have to do the same thing
> which is "wrong" and recommended against typically in several
> places ("Writing R Extensions").
>
> Of course, if there's no better solution, that's still a
> possibility, but this whole approach  "smells a bit bad" to me.
>

Of course it shouldn't be necessary but its R's own bizarre design of
the Date methods that cause the problem and recent changes to lock
down the namespaces mean that prior workarounds (which did not require
exporting) no longer work.  So, following R's own lead in having all
packages with as.Date methods fully export them seems the easiest
alternative.

Note that this is long standing functionality which pre-dated these
various changes in R so its R's own changes that caused the problem
and not any change in a user package.  Also note that the impact is
large since at the current point in time 74 packages have some sort of
dependency on or are used with zoo and 207 packages directly depend,
suggest, import or extend zoo or depend, suggest, import or extend a
package which in turn does (to one level).  If one recursively
includes all such dependencies to all levels then over half of all
packages on CRAN directly or indirectly have such a dependence on zoo
so the impact is significant.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com