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.
<snip>
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:
/home/wayland/xml/foo.xml/html/head/title/text()
Also there is the case of archived directories and files, eg.
/home/richard/archive/version2.zip/foo/text.txt
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:
IO::Dir.files()
IO::FileNode.lines()
IO::File.printf()
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 |
---------------------------------------------------------------------
----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-----
