On Sat, Feb 14, 2009 at 6:38 AM,  <pugs-comm...@feather.perl6.nl> wrote:
> +=head2 IO::Openable
> +
> +This role implies that the object can be connected to, or listened on.
> +
> +=over 4
> +
> +=item open
> +
> + method Bool open();
> +
> +Attempts to open the handle.  Depending on the implementation, this could be 
> an open()
> +call, a connect(), a listen(), or something similar.
> +
> +=back
> +

I'm not sure if I really hate or love this. I'm not quite convinced if
the use of it anyway.

> +=head2 IO::Socket
> +
> +role   IO::Socket does IO::POSIX does IO::Openable does IO::Closeable {
> +...
> +}
> +
> +=over
> +
> +=item IO.accept
> +
> +=item IO.bind
> +
> +=item Socket.pair
> +
> +    our List of IO method pair(Int $domain, Int $type, Int $protocol)
> +
> +A wrapper for socketpair(2), returns a pair of IO objects representing the
> +reader and writer ends of the socket.
> +
> +   use Socket;
> +   ($r, $w) = Socket.pair(AF_UNIX, SOCK_STREAM, PF_UNSPEC);
> +
> +
> +=back
> +

Why should this do POSIX? What about non-POSIX operating systems?

> +=item syscall
> +

That functions should be well hidden

> +=item sysopen
> +

I vote for sysopen (and all other sys functions) to be wiped out of existence.

> +=head1 Classes
> +
> +=head2 IO::File
> +
> +This does file input and output.
> +
> +class  IO::File does IO::POSIX does IO::Closeable does IO::Openable {
> +...
> +}
> +
> +=over
> +
> +=item init
> +
> + method init(String $filename, $options?);
> + method init(Int $fd);
> +
> + # Read
> + $fobj = new IO::File($filename);
> +
> + # Write
> + $fobj = new IO::File($filename, :w);
> +
> + # Read using file descriptor
> + $fobj = new IO::File($fd);
> +
> +Associate an IO object with an already-open file descriptor,
> +presumably passed in from the parent process.
> +
> +=back

Why should this do POSIX? What about non-POSIX operating systems?

Why is that function called init, and not open? That's rather non-intuitive.

This should do IO::Seekable and (to be written) IO::Stattable.

> +=head2 IO::FileSystem
> +
> +This reads directories, worries about ownership and permissions, and the 
> like.
> +
> +class  IO::FileSystem does IO::POSIX does IO::Closeable does IO::Openable {
> +...
> +}

Why should this do POSIX? What about non-POSIX operating systems?

> +=head2 IO::Socket::INET
> +
> +class  IO::Socket::INET does IO::Socket {
> +...
> +}
> +
> +=over
> +
> +=item  init
> +
> + method Bool init($RemoteHost, $RemotePort, $LocalHost?, $LocalPort?);
> +
> +=item open($Listen?);
> +
> +If $Listen is 0, it does a connect().  If $Listen is 1, it does a connect() 
> and a
> +listen().  If $Listen is 2, it does a listen(), but no connect().
> +

I *really* hate that interface, and I don't see how it covers an
accepting socket.

IMO there should be two calls

method IO connect($RemoteHost, $RemotePort, *%options)

where *%options can contain things like the local address,
non-blockingness, etc...

method IO::Accepting listen($LocalHost, $LocalPort, *%options)

role IO::Accepting does IO::Socket {
    IO accept();
}

> -=head1 Input and Output
> +=head2 IO::Pipe
>
> -=over 4
> +class  IO::Pipe does IO::POSIX does IO::Closeable does IO::Openable {
> +...
> +}

Why should this do POSIX? What about non-POSIX operating systems?

Regards,

Leon Timmermans

Reply via email to