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 >