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 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)
to type $x to a \w+: handled string, so MMD can see it. When means
you can pass a uri object to a generic open just fine, as long as your
program generates the type. But random strings wouldn't accidentally
trigger uri processing. Alternately,
open URI: $x
will single dispatch to the URI class.
: "open" as a POSIX function is not ambiguous at all. But will the POSIX
: model be the model on which P6 is based (as P5 was), or will the POSIX
: model simply be one of many models supported by open and other
: built-ins?
One of many.
: I think that it's fair to say that Perl has grown beyond POSIX. If it
: also presents the URI model, that's not all bad, is it?
As long as it's not the accidental default.
: Same goes for the Unix command-line conventions (e.g. cat's "-" special
: filename). I should be able to request a "pure POSIX" open, but I'm not
: sure it should be the default for one of English's most powerfully
: flexible verbs.
io() is probably the place for complete dwimmery.
: > and perhaps even
: >
: > File::Copy::copy("-","-");
:
: This brings up something interesting. If we have:
:
: sub File::Copy::copy(IO $file1, IO $file2) {...}
:
: the above doesn't work.
:
: I think I want:
:
: sub File::Copy::copy(IO $file1 :r, IO $file2 :w) {...}
:
: But does that work the way I think it does? Does that end up calling:
:
: IO.new("-", :r);
:
: and
:
: IO.new("-", :w);
:
: ? If not, how do I ensure that this works correctly?
Those are all pretty bletcherous. How 'bout
io('-') ==> io('-');
: > Sure enough, there's an easy way:
: >
: > class IO is ParrotIO does RegisteredStringConstructor {...}
: > role RegisteredStringConstructor {
: > has %:registry;
: > sub register(Any $pattern, Type $type) {
: > %:registry{$pattern} = $type;
: > }
: > multi method new(Str $string,*%rest) {
: > for %:registry.keys -> $pat {
: > if $string ~~ $pat {
: > return
%:registry{$pat}.bless(:string($string),*%rest);
: > }
: > }
:
: I would need some error handling here, and possibly would need to defer
: to a parent as a fallback.
:
: 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:
:
: use IO;
: {
: use IO::URI :open;
: open("http://www.perl.org/",:r);
: }
: open("http://www.perl.org",:r);
:
: opens two very different things: a socket to a host and port as directed
: by a URI vs a file named "www.perl.org" in a directory called "http:".
my &open ::= &open:(URI);
or maybe some kind of currying. Multiple handlers would need some way
of ordering them though. Seems like I put something into the delegation
model to deal with that already, like
has @:iolist handles <open>;
: > Optional export features of IO::* could allow:
: >
: > * pipeline command execution
: > * thread and/or process coupling
: > * handle duping
: > * much more
: >
: > Thus, you would control these features like so:
: >
: > use IO;
: > use IO::Funky :register_string_open_funkiness;
: > open("funk",:w);
:
: Which is probably just the tip of the iceberg. You might, for example,
: want to lay out a user-defined filesystem, or open database tables as
: files, etc.
I think lumping everything under the IO rubric is perhaps a mistake, unless
we also give shortcuts for all the common cases, in which case maybe we
should go for a flatter hierarchy to begin with, and leave the deep names
for CPAN modules.
: Of course, you can do all of this explicitly through OO syntax, but it
: would be nice to uniformly export locator semantics as strings so that
: command-line and other string-based user interaction could be made more
: powerful with a single "use".
Just so easy things stay easy. Foo::Bar::Baz::meth names are not
construed by everyone as easy to use.
Larry
