Resent to list as I intended to in the first place....
On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncan<dar...@darrenduncan.net> wrote:
> Mark J. Reed wrote:
>>
>> A few months ago (or maybe more) I proposed making pathnames their own
>> type, distinct from (or perhas a subclass of) strings, but easily
>> constructed from strings, maybe with an operator. Having those 29
>> single-letter methods on such a class would not bug me as much as
>> having them on Str.
>>
>> On 7/9/09, Aristotle Pagaltzis <pagalt...@gmx.de> wrote:
>>>
>>> * Moritz Lenz <mor...@faui2k3.org> [2009-07-10 00:25]:
>>>>
>>>> stat($str, :e) # let multi dispatch handle it for us
>>>
>>> This gets my vote.
>
> I agree. The built-ins of basic types like Str or Int etc need to stay pure
> and just be about dealing with local data. Having methods on basic types
> for going out into the wider environment like the file system is just plain
> wrong. There should be separate IO classes for things like stat, which
> *use* basic types like Str for their interface definitions, and the full
> definition of Str/etc should not include any file-system operations.
It's unclear which you are agreeing with. By reference, it sounds
like you agree with the idea of a separate pathname type, but by
context, it sounds like you are agreeing with stat($str, :e)
Both the separate pathname type and the stat($str, :e) proposal
salvage the purity of Str, so either would be acceptable to your
argument.
I have seen other language APIs have a pathname class, usually called
FilePath or Path or similar. Generally, I like the idea because it
allows one to abstract away from the specific form of a filename (be
it the /home/blaisepascal/.emacs/emacsrc of Unix, the C:\Documents and
Settings\Users\Blaisepascal\Local Settings\GNUEmacs\emacs.rc of
Windows, the BootDisk:Users:BlaisePascal:Settings:GNUEmacs:emacsrc of
MacOS 9, or the DKA0:[USERS.BLAISEPASCAL.SETTINGS.GNUEMACS]EMACS.RC;1
of VMS) to the basic components (devices, directories, and files).
Most of the FilePath APIs I've seen allow virtual traversal of the
path (e.g., given a FIlePath corresponding to
/home/blaisepascal/.emacs, you can ask it for the directory portion to
get /home/blaisepascal, or ask it to specify another layer, to get
/home/blaisepascal/.emacs/22.18), conversion of relative paths to
absolute paths, and perhaps even conversion of one path representation
(like Unix-style paths) to another (like HFS-style paths).
The annoying bit I've found with some APIs is that some of them force
you to use a FilePath as an argument to File.Open(), and don't always
provide an easy way to get from a string to a FilePath, forcing you to
do things like File.Open(FilePath.CurrentWorkingDirectory.AddFileName("myFile"))
to open ./myFile.
I support the idea of a separate pathname type, and I trust the Perl6
developers to make it robust but easy to use.
>
> If you go ahead and put stat ops in Str anyway, then you might as well put
> things like a delete_from(Hash $arg) method on Object, which is a less
> objectionable version of such backwardness.
>
> -- Darren Duncan
>
