From murdoch at stats.uwo.ca  Wed Jun  4 13:03:00 2008
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Wed, 04 Jun 2008 07:03:00 -0400
Subject: [Rd] savePlot() no longer automatically adds an extension to
 the filename.
In-Reply-To: <971536df0806031950m663c6154v3b92bffed7c16bd6@mail.gmail.com>
References: <s8456fea.037@tedmail.lgc.co.uk>	
	<ou2b449rirr8tkv0con6u598vhocp2kmfk@4ax.com>	
	<4845E463.8020907@stats.uwo.ca>	
	<105532E2-2C4C-4299-81B2-CA949078C468@r-project.org>
	<971536df0806031950m663c6154v3b92bffed7c16bd6@mail.gmail.com>
Message-ID: <48467664.2090703@stats.uwo.ca>

Gabor Grothendieck wrote:
> On Tue, Jun 3, 2008 at 10:36 PM, Simon Urbanek
> <simon.urbanek at r-project.org> 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.
>>
>> 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 canf 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...
>>
>>     
>
> One way to fix this so that the filename is a complete name is to derive
> the default type from the filename rather than the default filename
> from the type.
>
> That is if type is not specified and the last four characters of the file name
> are .wmf, .jpg, ..., etc. then the type would be set to that.
>   

I think that would have been a better design when savePlot was 
introduced many years ago, but the goal here is to maintain back 
compatibility.  It wouldn't help with that, because before February, 
savePlot got the type from the "type" arg, and modified the filename to 
match.

Duncan Murdoch



[Rd] savePlot() no longer automatically adds an extension to the filename.
Duncan Murdoch