On Sat, 14 Feb 2009, Leon Timmermans wrote:
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.
I like it if we can make it work, but it may be too nonsensical to get
anything useful out of it. See my discussion below.
Why should this do POSIX? What about non-POSIX operating systems?
This was an example of me not thinking. Basically, it was because
it was easier than writing IO::Readable IO::Writeable. I'll ignore the
question as it crops up throughout; someone feel free to replace POSIX with
something else.
I haven't written a program that was intended to be run on anything
other than Unix or Embedded in years, so I'm quite pleased to get some input
from non-POSIX types. I'm happy (once we sort out what we're doing) for
others to edit the thing, now that I've gone and restructured it all :).
As a rakudo user, I'm also wondering whether we shouldn't be referring
more to the Parrot IO stuff, but that may just be me.
http://www.parrotcode.org/docs/ops/io.html
+=item syscall
+
That functions should be well hidden
Question -- is there a reason this is in IO, instead of eg. S29? If
not, I'll move it there.
+=item sysopen
+
I vote for sysopen (and all other sys functions) to be wiped out of existence.
Disagree -- I think these belong in IO::Unbuffered. Maybe we could
make that optional, though :).
+=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 is that function called init, and not open? That's rather non-intuitive.
Hmm. I still haven't gotten the hang of Perl 6. What I want is for
the name of this function to be the one that automatically gets called on
object creation. Then you do something like this:
$fobj = new IO::File($filename); # Creates handle
$fobj.open(); # opens file
This should do IO::Seekable and (to be written) IO::Stattable.
Should it? I'm just thinking about the interactions between IO::File
and IO::FileSystem. Maybe I'm just wondering about the name :). I'd argue
that maybe
class IO::File ... {
has IO::FileSystemEntry $FSEntry;
...
}
...and that you could then do:
$fobj = new IO::File($filename);
if($fobj.FSEntry.ModificationTime > '2008') { print "Modified this year\n"; }
$fobj.open()
...
In other words, I'm arguing that maybe we need a separate class for
the calls that do stuff to the "outside" of a file, verses the calls that do
stuff to the "inside" of a file. But maybe that's what roles are for.
I'm undecided. Thoughts, anyone?
+=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.
Ok, I agree there's room for improvement, but I'm not 100% sure I
agree on the details.
IMO there should be two calls
At least 3 :).
method IO connect($RemoteHost, $RemotePort, *%options)
where *%options can contain things like the local address,
non-blockingness, etc...
I'd break this into two; one like the init call above that creates the
object, and has the local and remote host/port passed in, but doesn't do any
calls.
Maybe something like this example for a client:
$socket = new IO::Socket::INET($RemoteHost, $RemotePort, OtherOption => 1);
$socket.Blockingness = 1; # Ok, maybe not blockingness, but you know what I
mean
$socket.OtherOption = 0; # Changed our mind from what we said in the class
creation call
$socket.open(); # This could be called "connect", maybe
I'm kinda keen to call the function open() instead of connect(), so
that things are more consistent across the whole IO interface, but I agree
that attaching the listen stuff to that call was a bad idea.
For the server, I'd suggest an additional role, IO::Listening, that
has both listen() and accept() calls on it. Would that work for you? Or is
that essentially exactly what you suggested below, but with a name change? :)
method IO::Accepting listen($LocalHost, $LocalPort, *%options)
role IO::Accepting does IO::Socket {
IO accept();
}
HTH,
---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: wayl...@wayland.id.au | I am |
---------------------------------------------------------------------
----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----
