What I mean to say is, well, it seems to say that all IO is the same, and that implication seems to imply the following meaning...when, in reality, these things that are being joined as one all are different...leaving me inclined, I think, to keep doing everything seperately in the name of understanding.

io('/tmp') >> io('server.com:9999');
[download]

So the question is, is that sensical? We're just routing IO right? What about routing a socket to append to a directory? If we have this code work on arbitary scalars, we really don't know what is going on, and not all operations are valid.

$x='server.com:9999';
$y='/tmp';
io($x) > io($y)
[download]

So what are the rules that define when this operation works correctly for any $x and $y ... is this obvious? Is this something that can be tested for programatically?

Anyhow, definitely some spiffy concepts, and I apologize for putting on my manager hat :) It just seems to raise questions of maintainability and whether or not all is obvious. In most modules, hidden DWIMerry is cool, here though, the goal is simplication, and I think that hidden DWIMerry could (and I might be wrong) lead to trouble.

Feel free to open up for debate. I'm convinceable. I can also be bribed with cash or steak.

I gave your snippet that makes no sense a shot. I was surprised to get an error considering the docs say that no validating is done. But here you are (and you know any DWIM behaviour out of this really wouldn't make sense right?):

#!c:/perl/bin/perl -w
$|++;

use strict;
use IO::All;

my $x = 'localhost:12345';
my $y = 'c:/servdata';

io($x) > io($y);

__END__
Undefined behavior for overloaded IO::All operation: 'socket > file' a
+t C:/Perl/site/lib/IO/All.pm line 840.
[download]

Darn, there was a sadistic part of me that was wishing this might do something really bizarre, but yeah, I'm glad it didn't work. It certaintly does make you ask what that operator really is, though... I figure if you can't surmise an operator's purpose in a few words you have a rather confusing operator.

% = modulus

> is less than, except when both sides are an IO::All, undefined if IO:All on one side, but IO:All must be a file, or possibly a socket, but never a directory, but sometimes a port, and ... err...

I agree. And the stuff about inheriting exporting made my skin crawl. It's a neat trick, but it's not something I'd be happy to see in code I had to work on.

Just be sure and read the STABILITY section in the docs:

"... I will not hesitate to break backwards compatibility with other versions of IO::All if I can find an easier and clearer way to do a particular thing."

That doesn't mean don't use this module. Do use this module. Just don't use it in your production code ... yet.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

In PHP, you have to scrub GET/POST parameters to be used as part of a filename, because PHP's open() understands URLs and you don't necessarily want to be fed data from remote systems.

There's also a reason I exclusively use 3-argument open in Perl.

Sure, IO::All sounds like a keen idea at first, but I feel really uneasy looking at that code. How can I be sure I won't be surprised by at it at some point? Yes, you can be explicit in your expectations with IO::All, but then it loses brevity and thus appeal. The operator overloading makes me convulse. I find it ugly.

I'd prefer a module that makes it easy to be explicit over one that reads intentions into what I tell it.