On Sat, Feb 14, 2009 at 6:38 AM, <[email protected]> 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
