[Rd] savePlot() no longer automatically adds an extension to the filename.
Duncan Murdoch
murdoch at stats.uwo.ca
Wed Jun 4 12:53:42 CEST 2008
Simon Urbanek wrote:
> On Jun 3, 2008, at 8:40 PM, Duncan Murdoch wrote:
>
>
>> On 03/06/2008 2:35 PM, Mike Prager wrote:
>>
>>> "S Ellison" <S.Ellison at lgc.co.uk> wrote:
>>>
>>>> Plaintive squeak: Why the change?
>>>> Some OS's and desktops use the extension, so forgetting it causes
>>>> trouble. The new default filename keeps a filetype (as before) but
>>>> the
>>>> user now has to type a filetype twice (once as the type, once as
>>>> extension) to get the same effect fo rtheir own filenames. And the
>>>> extension isn't then checked for consistency with valid file
>>>> types, so
>>>> it can be mistyped and saved with no warning. Hard to see the
>>>> advantage
>>>> of doing away with it...
>>>>
>>> Just for the record. . .
>>> This change broke a *lot* of my code, including code used by
>>> others. Windows depends on file extensions. Fortunately, fixes
>>> using getRversion are not too difficult.
>>>
>> Then you'll be happy to hear that Steve put together a patch and
>> it's already committed, so it should make it into 2.7.1. The patch
>> adds the extension if there's no dot in the name, leaves the
>> filename as-is if it sees one. So this should be compatible with
>> the majority of uses, only messing up cases where people really
>> don't want an extension (now they'll have to add a dot at the end of
>> their filename), or where they want an automatic one, but have
>> another dot in the name.
>>
>>
>
> AFAICS the savePlot() behavior is now (as of r45830) inconsistent
> across platforms due to the patch (r458229). The inconsistency is IMHO
> a bad thing - you shouldn't expect the same function to behave
> differently across platforms.
>
savePlot has been a Windows function for at least 4 years, defined in
the grDevices/R/windows directory, and documented in the
grDevices/man/windows directory. An incompatible X11 version was added
in February 2008. So if compatibility across
platforms is the goal, we should change the X11 version to match the
Windows version, not vice versa.
However, the convention of automatically adding an extension is a
Windows convention, not a Unix convention. So I think that would be a
bad change. This is a user interface issue, and it is reasonable to
have differences in user interfaces across platforms.
> I'd strongly recommend against this change for several reasons: it
> changes the behavior of the function between 2.7.0 and 2.7.1, so that
> now you have to special-case three different versions (pre 2.7.0,
> 2.7.0 and 2.7.1), there is now no way to specify a file without a dot
> (which is quite common in non-Windows world) and the behavior is
> incompatible with other similar functions.
>
> I think the change of behavior in 2.7.0 was deliberate and in favor of
> consistency, because a filename specification should not be randomly
> mangled by the function (I have made that mistake myself before, so I
> know the pitfalls ;)). Extension is part of the filename, it's not a
> separate concept (also note that ".foo" is a valid filename that
> doesn't have an extension). The argument about typos is moot since you
> can always define functions like
> saveFoo <- function(prefix) savePlot(filename = paste(prefix, "foo",
> sep="."), type="foo")
> At any rate I don't see how this can realistically be part of 2.7.1
> since it's not a bugfix and it changes the meaning of a function
> parameter. (And I usually don't mind disguising small features as
> bugfixes ;P)
>
> Whether the change in 2.7.0 could be done differently (e.g. using
> another parameter for a full file name) is a different story, but I
> suspect that it should have been discussed before the 2.7.0 release...
>
>
I agree it should have been discussed earlier, but it wasn't. There are
lots of precedents for behaviour changes between .0 and .1 releases, for
the sake of back-compatibility.
So I think Steve's change is appropriate, and I'm planning to leave it in.
Duncan Murdoch
> Cheers,
> Simon
>
>
More information about the R-devel
mailing list