Actually, it seems to me that we do agree fundamentally, although using
different terminology.
And like I said in an earlier email, I do like/agree with the way you
are taking the Spec.
Also, it seems to me a re-ordering of the material in the Specs would
make more sense.
On our disagreement:
Timothy S. Nelson wrote:
On Wed, 18 Feb 2009, Richard Hainsworth wrote:
<snip>
$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.
I suspect this is where our disagreement comes in. I don't agree
that it's an artifact of the OS. Can you give me an example of an OS
that doesn't work that way?
OK and when I wrote this I knew I was half-wrong.
Its just that in my view of a directory as a location container, my idea
was that the methods available on the container would yield different
sorts of contents. Hence,
my $dir .= new IO::Dir($path); # Note the .= is perl6 for the mutating
method new, not a = as in perl5
my @files = $dir.files; # I think this is correct in that here the array
is not typed.
my @subdirectories = $dir.children;
#But if File is a type, then I am not sure what the correct syntax would
be. Perhaps
my @files of IO::File <== $dir.files; # lazily evaluated
my @subdirectories of IO::Dir <== $dir.children;
I dont think your @$dir is correct because you have an object $dir, not
a pointer to an array, which is implied in perl5 by the '@$' syntax.
For what you want, I would think, you need
@files = grep { :f } $dir.contents; # note the adverbial form, which is
mentioned in one of the other specs.
By analogy there would be
@subdirectories = grep { :d } $dir.contents;
And here, as above in my example, although we have explicitly declare
dir as a IO::Dir object, we have not declared the directories in
@subdirectories as IO::Dir, which they are too.
However, in so far as our disagreement is concerned, it seems to be one
of style rather than substance.
I would prefer methods on objects that yield the various types of
content, you would prefer adverbial tests to be used on all contents.
Mind you, I think in one of the other Synopses, I read that the
adverbial form actually translates into a method, so both are equivalent.
<snip>
None, I agree. But even things on the Internet can have container
attributes. That would be eg. HTTP headers. Maybe not *everything*
has attributes on the container, but it seems to me that almost
anything I can think of does.
I'll be interested to see where this heads next :).
Me too :)
So, for starters:
Can we abstract enough so that there is no difference between a database
producing data and a file producing data?
Given that a file containing archive data or xml/html data is both a
source of data, but also a container / location. Consequently, if File
and Directory are types, then if a file does contain data then the
filehandle associated with it can be coerced into the Directory type?
Just as Int can be coerced into Num.
What needs to be abstracted so that a perl6 program can know that a
Writeable may not be able to accept data (eg., because the file system
is full)?
How about connections eg., to internet sites, that were working, but
have broken during software operation.
