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-----

Reply via email to