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 
: >                             }
: >                     }
: 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.

  • Re: stdio Larry Wall

Reply via email to