Timothy S. Nelson wrote:
On Tue, 17 Feb 2009, Richard Hainsworth wrote:

Timothy S. Nelson wrote:
<snip>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.

Like == agree
Like !=== agree
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.

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).
Interesting. But how is inside/outside different from container/contents ?
Methods on a container are different to methods on the content.
My idea is that a location is a container, file is also a container, but of another sort. I was thinking that by identifying locations as specific types of containers, it would be possible to create an abstraction for perl6 specification that is less OS sensitive.
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:

Also there is the case of archived directories and files, eg.

Version2.zip is considered by the OS as a file.
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.
Well, even here, <html> <head> and <title> all define conceptual containers within the marked up datastream. But the datastream is defined as a string of octets, and in this example, the initial string with something like

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

has been ignored in your example. So it is not the perl6 core that is allowing path definition to an html fragment.

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.
So I was not entirely right in saying .files has no meaning for a file, if the file is a zip archive. But both can be considered locations, even though for unix/windows a zip file is considered a file.

But isnt that a feature of the OS?
    I'd argue that we want three things here, if we go down this path:


No I dont think so. There is a difference between a source of data and data. For example, suppose we set up a connection to a database that generates multiple lines and we associate (I am guessing about the syntax here) the data base response with a filehandle my $fh = $database.connect('select "Month","Name", "Capital", "Total_Assets" from "Banks" where id "month" > "20071201" ');
for =$fh -> @record {...};

The data stream is in lines, but the source is not a file. Yet supposing, the same data had been saved to a file and $fh had been associated with the file as a source. As far as the code in the for loop is concerned, it is the same data stream.

But the data stream generated from querying a location where a number of files are located in a filestore is different from the datastream from file.
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;
But this is exactly what I think should be avoided. -f implies that the location $dir contains things other than files. But that is an artifact of the OS and should be hidden within the implementation of perl, or made available by a OS-specific package.

When I started learning perl (I used Windows platform at that time) I was confronted with a bewildering array of functionality. Some was part of perl and I could use, nearly all the IO functions were specific to Unix, and I never ever used. But I spent a considerable amount of time working out what was and wasnt useful to me at the time.

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.


Yet links, devices, pipes, etc are OS-related artifacts. Even now the internet provides access to locations with datasources. If someone is wholly concerned with data from the internet, eg., web cams and databases, of what interest is a /dev file in a unix filesystem?

| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayl...@wayland.id.au    | I am                           |

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-

Reply via email to