Em Sáb, 2009-02-14 às 18:01 +0100, Leon Timmermans escreveu:
> 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.
> I'm not sure if I really hate or love this. I'm not quite convinced if
> the use of it anyway.
Maybe I'm thinking sideways again, but I haven't thought of "open" as
being a method of any IO object, because usually "open" is the thing
that gets you an IO Object.
I'd expect the plain "open" to be really a sub (maybe a "is export"
method in the generic IO role), that does whatever it needs to do to
provide you an IO object, including composing the roles according to the
features it supports.
One important thing here, is that the roles are not intended to
represent attributes of the object. For instance, IO::Readable and
IO::Writeable are not going to be composed depending on the parameters
you send to "open", but if you're in a Linux system, it should probably
return an object that does IO::Linux26 (which does IO::POSIX[$SomeLevel]
does IO::BSD[$Somewhat], which should also compose IO::Readable and
IO::Writeable independent of the open mode).
So the idea is not about having the object to have the roles dinamically
composed and de-composed depending on the access mode, but to have a way
to implement a custom IO object that performs only the features it want
to implement and yet being able to be used interchangeably with other IO
objects.
That way, in the code that uses an IO object, if you want to be able to
do unbuffered raw read from the object you receive as argument, you use
sub foo(IO::Readable $bar) {...}
and that way, it should be easy to provide a entirely made-up IO object
that can be used by foo without any harm or magic.
daniel
