Em Qua, 2009-02-04 às 16:45 +0000, Aaron Crane escreveu: > pugs-comm...@feather.perl6.nl writes: > > +=item method Int read($buf is rw, int $length) > I'm not sure that using a native int is the right thing here. If > whatever the implementation uses as int is narrower than size_t, that > forces the programmer to use an Int and do the necessary loop.
native int can't be undefined, failures are undefined. The use of Int here is to support it returning unthrown exceptions. > > +=head2 IO::POSIX > > + > > +Indicates that this object can perform standard posix IO operations. > I don't like that wording, but getting it right seems tricky. The > problem is that I don't think you mean for IO::POSIX to contain > methods corresponding to POSIX-ish read(2), write(2), given that > methods of those names exist in other roles. But those are precisely > what I'd think of as most obviously falling into the category of > "standard POSIX I/O operations". That actually surprised me, for some reason I did think read and write were standard C, not POSIX (that's what happens when you don't have experience in non-unix OSs). And maybe you're indeed right, since you can change the way you access a file in POSIX, it would be strange to de-compose a Writeable role if you change the way you access the io. but having separated roles for read and write would make it easier to implement application level io objects (not backed by operating system file descriptors). That probably means IO::POSIX does IO::Readable does IO::Writeable. > > +=item method Bool flock(:$r,:$w) > I realise this part of the specification still seems to be at the stub > stage, but I'll note that: Yes, it was meant purely as an example, a more carefull planning of that would be needed. daniel
