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