Question about UIOP: Any reason GET-TEMPORARY-FILE couldn't be exported?
rpgoldman at sift.net
Mon Aug 22 22:45:05 UTC 2016
On 8/22/16 Aug 22 -5:16 PM, Faré wrote:
> On Mon, Aug 22, 2016 at 5:48 PM, Robert Goldman <rpgoldman at sift.net> wrote:
>> I am translating some existing code that does something like the following:
>> concatenate f1 and f2 > temp file 1
>> concatenate f2 and f1 (i.e., reverse concat) > temp file 2
>> compute function of temp file 1
>> compute function of temp file 2
>> return minimum of f(temp file1), f(temp file2)
>> I did this using "cat" for which it is more convenient to have the name
>> of the file than the stream.
>> In general, when invoking the shell, the shell "speaks" names, not CL
>> Now, as you said, I could simply replicate the logic of
>> GET-TEMPORARY-FILE, but since GET-TEMPORARY-FILE pretty much replicates
>> the interface of mktemp, which the shell wizards consider to be
>> valuable, I think there's precedent for something like
>> GET-TEMPORARY-FILE being supplied. Although, perhaps calling it
>> GET-TEMPORARY-FILENAME would be better.
>> Is there some reason it would be inappropriate to export this?
> It's an unintentional omission indeed that
> UIOP/STREAM::GET-TEMPORARY-FILE wasn't exported. I thought I had
> exported it, but I failed to. The function has existed since 3.1.2
> (i.e. the first stable 3.1 release).
Since it has never been exported, I believe we can safely rename it. I
note, actually, that my proposed renaming is also wrong. It should be
GET-TEMPORARY-PATHNAME not FILENAME, right? Since we get back a CL
pathname and not a namestring. At the expense of a slightly fatter
interface, I'm tempted to add both:
GET-TEMPORARY-PATHNAME returning a pathname and
GET-TEMPORARY-FILENAME returning a filename (string)
The former is more natural for CL, but the latter is more useful when
interacting with anything that is not CL.
> Note that in most cases, you'll have cleaner code using
> WITH-TEMPORARY-FILE, though (also to be considered debugged since
Yes, I agree. For interop with the shell, though, this API may be handier.
More information about the asdf-devel