Nothing makes you re-think your reply length like having your mailer
lose your message ;-)
A lot of your message revolves around this idea that there's a "normal
file open" semantic. What I've tried (but clearly failed) to articulate
previously is that this notion is becoming archaic in what is shaping up
to be the post-POSIX world. Gnome VFS and the .NET Framework are good
examples of this.
Now, I don't think that the state of the world is yet such that we can
say that Perl should embrace the Gnome VFS or .NET Framework or whatever
OS/X does or any other meta-file-framework on people, but I do think
that we can safely expect Perl 6 to have to deal with these concepts and
would be well served by building in a standard way to add your More Than
One Way later on through CPAN.
On Fri, 2005-05-06 at 15:10, Larry Wall wrote:
> On Fri, May 06, 2005 at 08:19:05AM -0400, Aaron Sherman wrote:
> : "open" as a verb is extremely ambiguous. In dictionary searches I see as
> : many as 19 definitions just for the verb form.
>
> Well, sure, but also need to take Perl history into account, where dwimmy
> open is considered something of a liability.
I've come across many folks (and I'm one of them) who a) like the "-"
magic a lot and b) are in the majority in my experience. I definitely
see the concern around adverbial bits showing up in the text (e.g. ">"
and "<"), but not magical filenames like "-". Three-argument open is a
godsend, but I'd love to preserve the bits that were useful in Perl 6.
> I think the dwimminess of open() probably arises only from MMD, and
> a string or array of string in the first argument implies ordinary
> file open. That means perhaps we have
>
> open uri($x)
Ok, I had a long reply to this, but I'll sum up:
* open uri($x) implies that I know that $x is a URI.
* Being able to "use IO::URI :stropen" makes an otherwise
cumbersome chore into a breeze, e.g.:
use IO::URI :stropen;
use IO::SomethingElse :stropen;
GetOptions('f|file' => \$input_file);
my $input = open($input_file, :r);
* I don't think any of this should be on by default, with the
possible exception of "-", but that's only possible.
> :
> : sub File::Copy::copy(IO $file1 :r, IO $file2 :w) {...}
I think you took this as a request for long, "::"-separated names in
everyday code. I was just being verbose for one-line clarity, not
because I think subdefs should look like that in real code. To be more
specific:
module File::Copy is export<copy> {
sub copy(IO $file1 :r, IO $file2 :w) {...}
}
And I was asking if that would pass the adverb down to the constructor
for IO like so:
$file1 = IO.new($param, :r)
and if not, how one can do that.
> Those are all pretty bletcherous. How 'bout
>
> io('-') ==> io('-');
In Perl 5, File::Copy::copy is not a pipelineable (or potentially lazy)
operation because it can be implemented by OS-level special-purpose
functions. I think that overloading infix:==>(IO $a,IO $b) to behave
this way would be potentially very misleading to the programmer, and
thus should probably be left alone.
Should file copying be a core function or a module as it was in Perl 5?
I don't know, but either way I think it needs to continue to make OS
specific copying available for the six or seven platforms that Perl 5
currently knows about.
[...example code...]
> : I would need some error handling here, and possibly would need to defer
> : to a parent as a fallback.
Sure, that all makes sense. I was white-boarding, and haven't even yet
solved the problem of scoping the change.
> : That brings up the idea of delegation... should this be handled by
> : delegation instead of the way I've done it? Not sure. I'm still trying
> : to figure out how to make this scope correctly so that:
Delegation might work very well here. There was a nice use for it that I
had in mind for IO::Pipe as well. I have to re-read the array delegation
rules to see how that behaves, but thanks for reminding me of it.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
