Resent to list as I intended to in the first place....
On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncanwrote:
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 wrote:
* Moritz Lenz [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
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