On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
Hi all. I know we usually run on forgiveness instead of permission,
but I'm suggesting a big change (or extension, anyway), so I wanted to run
the ideas by you all before I put the effort in. If I don't get feedback,
I'll just make the changes.
The first thing I wanted to suggest was that in S16, the OS-specific
stuff be split out into separate roles. I suspect this is mostly
non-controversial, so I'll do that unless someone complains.
My second thought is that we need to specify tree objects (see
http://www.mail-archive.com/perl6-language@perl.org/msg28579.html ). I'll
put them in S16 unless someone complains.
My third thought is that it would be very useful also to have date/time
objects that integrate well with eg. ctime, mtime, and the like; I'd start
with Time::Piece as a model.
http://search.cpan.org/dist/Time-Piece/Piece.pm
My final question is, since people are now getting somewhat familiar
with the "file:" URI scheme (ie. file:/home/wayland/Notes.txt or
file:/C/Documents and Settings/wayland/Notes.txt or whatever), I'm
wondering if this isn't how we should be specifying our files; it's
prettier than File::Spec :), and unified.
Anyway, HTH,
I like all the default suggestions.
Not sure whether this means you completely agree with me, or
completely disagree.
It seems to me that a path, whether within a file system or across the
internet, leads to a location. A location is a container for files. A file is
a container for data.
Given the strong typing paradigm of Perl6, it seems to me that the
specification should distinguish between files and locations.
It seems to me that unix blurs the difference between a file and a directory
(at least readdir returns both file and directory names and the programer
then needs a test to distinguish them), but that does not mean they are not
conceptually different.
I think you're confusing the inside and the outside of files. For me,
the inside of a file is everything you can do to it when you've done an open
(eg. read and write). The outside of a file is the other stuff (stat, chown,
etc).
Let me give you an example. Say I wanted to specify a path to a
particular XML element, starting from the root of a filesystem. Say also, for
argument's sake, that when the search path came to a file ending in .xml, it
would, if there were children requested, read the file and dig through the
tree. Then I could do something like this:
/home/wayland/xml/foo.xml/html/head/title/text()
Note that the directory called "xml" doesn't contain the file called
"foo.xml". Instead, it contains a filesystem entry called "foo.xml". This
filesystem entry in turn points to the contents (which I look at with an XML
path).
In other words, note the distinction between the *contents* of the
file, and the entry in the file system that refers to it. Which is the file?
Colloquially, both, but I'd argue that technically, the file is the
*contents*, not the filesystem entry.
For example, it is sensible to have a .files() method for a directory, but it
is not sensible for such a method to exist for a file. Meanwhile,
print/say/putc are not sensible for a directory/location.
I'd argue that we want three things here, if we go down this path:
IO::Dir.files()
IO::FileNode.lines()
IO::File.printf()
However, it seems to me that maybe the .files() method is heading in
the direction of PHPs 1001 string functions. It might be better like this:
$dir = new IO::Dir("/home/wayland");
@files = grep { -f } @$dir;
I know @$dir is bad perl6, but I hope you'll take the idea, in that,
when we treat $dir as an array, we get a return of all children, whether files
or directories, and then use -f to distinguish between them. Btw, the
object creation line above could be done differently -- don't anyone get hung
up on that.
Moreover, if perl6 distinguishes between a location and a file, then the spec
can distinguish between a .children() method that provides a list of child
locations (viz., sub-directories) and .files(), which provides a list of the
contents of the location.
Keep in mind that files and directories are also not the only things
in a filesystem. There are links, devices, pipes, and others to worry about.
Which is why I prefer my solution.
:)
---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: wayl...@wayland.id.au | I am |
---------------------------------------------------------------------
----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----
