Front page | perl.perl6.language |
Postings from February 2009
Re: IO, Trees, and Time/Date
Thread Previous
|
Thread Next
From:
Timothy S. Nelson
Date:
February 17, 2009 19:08
Subject:
Re: IO, Trees, and Time/Date
Message ID:
alpine.LRH.1.10.0902181351180.17863@gwalcmai.nelson.org.au
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: wayland@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-----
Thread Previous
|
Thread Next