On Tue, Feb 3, 2009 at 8:34 AM, Richard Hainsworth <rich...@rusrating.ru> wrote: > I strongly believe the current S16 needs rewriting from scratch. This > approach seems far more more perl6-ish. I tried to draft a new S16, but > realised I simply dont have the knowledge (or the time to acquire the > knowledge) necessary for even an initial draft. But in trying, these are > some of the ideas I had.
I fully agree. > c) the file tests :r and :w are not adverbs. They are methods on File > objects to determine the properties readability and writeability and return > Booleans. Things which are different should be named differently. Also, in > my (very limited) experience, testing readability and writeability are less > frequent in use than opening for read and write, thus for Huffman reasons, > they should be longer. May be .readable .writeable? I think what S16 currently proposes is just fine. > d) The vast majority of S16 seems to be about functions that are essentially > wrappers around unix calls. To be honest, I have never used most of them > within a perl program. Yeah, many of them should be moved to POSIX::, and/or be replaced by something better. > When originally developed, it was to fill a need > directly related to managing unix systems. There are now better tools for > these tasks, so perl6 does not need to address them in the core. I'm not sure what you mean with that. I don't think there is any reason why Perl 6 is inferior to some other tool for managing unix systems. If it is, we should fix that. > The success > of perl on the internet was due to the much deeper design values > incorporated in perl and that these deeper insights were more adaptable to a > different environment. There are now a variety of tools for handling the > internet environment. Perl6 - I believe - is now addressing an even wider > set of issues - a larger problem space. Leaving unix wrappers in the core > specifications will tie it down and perhaps hinder its development. Suppose > perl6 becomes the defacto language for an internet browser, IO would not > even be related to files or an operating system.) We have pluggable preludes. We can neutralize that problem easily. > g) Statbuf is mentioned in S03. It is not really dealt with in S16. It seems > to me from the context in S03 that Stafbuf is a sort of 'eager' filehandle, > in that the whole file is pulled into memory and then can be operated on. If > this is the case, would it not be more appropriate for the eagerness to be > defined as an adverb for 'open()' ? eg. > my $filehandle .= open(<name>, :r, :e); > Wouldn't this eliminate the need for Statbuf as a defined object type? > No, it's just the caching result of stat(), that happens to remember what file/handle is was called on. It seems S03 and S16 disagree on the meaning of $filename ~~ :e though. According to S16 it means $filename.:e, according to S03 it means $filename.e. I think it was discussed some time ago and S16 is correct. > h) Would it not be possible to write the IO specification in such a way as > to make everything 'outside' the program a single category of IO? Thus > files, http and ftp connections are all streams into containers and the same > verb ( 'open()' ) with attendant adverbs (:w, :r) are used to establish them > and the same set of tests (.readable, .writeable) used to verify the steams > have the required properties at some point in the programe. All directories > and urls would all be locations with the same methods to discover container > objects (files, archives, databases) in them. > There's nothing special about IO objects. Nothing is stopping anyone from writing their own objects implementing the IO roles (in fact, roles encourage doing just that). I don't understand what's the question, really. Though if you mean with open() that is should do what PHP's fopen does (open anything, from files to http connections and more): absolutely not. That's the kind of behavior that must be explicit, else we open up to a whole range of security problems. Regards, Leon Timmermans
