On Wed, 18 Feb 2009, Richard Hainsworth wrote:
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.
Yup, thanks.
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.
Hmm. That's not something I can find, but if you see it anywhere, let
me know.
<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?
If by "database", you mean "query results", probably, if
input_field_separator is defined on the file.
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.
In the case of archives, I'd argue "yes".
In the case of XML, I'd argue no, but it should be possible to coerce
it into another Tree::Node type. Since both directories and XML would both
implement the Tree::Node role, they'd have a fair number of common operations.
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)?
See other e-mail in this thread :).
How about connections eg., to internet sites, that were working, but have
broken during software operation.
That should hopefully change the isReadable/isWriteable, but if not,
then read/write calls can throw an exception.
:)
---------------------------------------------------------------------
| 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-----
