On Mon, Mar 06, 2006 at 01:08:55PM +0100, Leopold Toetsch wrote:
> * opcode vs function / method
>
> open P0, "data.txt", ">"
> print P0, "sample data\n"
>
> Using opcodes for all the IO has some disadvantages:
> a) namespace pollution: all opcodes are reserved words in Parrot
> b) opcodes aren't overridable, that is you can't provide your own
> 'print' opcode for e.g. debugging
> c) all such IO opcodes have to verify that the given PMC is actually a
> ParrotIO PMC.
>
> E.g.
>
> new P0, .Undef # or .Integer, ...
> print P0, "foo"
>
> I'm in favor of using methods for almost all IO functionality:
>
> P0.'print'("sample data\n")
I feel more comfortable with the idea of IO being methods on PMCs than raw
OPs. Not totally sure why. It's at least partly the ease of having "safe"
compartments that ban IO simply by preventing the creation of those PMCs.
However, I think that the biggest thing is seeing how the Perl 5 IO works,
where all the IO ops have to redispatch if the "file handle" turns out to be
tied, and in turn the PerlIO system has a whole second level of redispatch
at the C level of "overloading the file handle's behaviour". Oh, and then
there's PerlIO::via which hooks that C level back up to Perl methods.
So a single level of method calls feels much cleaner, as that means only 1
level of dispatch, however the program is re-implementing IO, be it writes
to tied scalars, character set conversion, or merely a direct IO with the
most native operating system interfaces.
> Combined with ...
>
> * [ return code vs exception ]
>
> ... we can also check, if this was a void call or not (Parrot *does
> have* the concept of a result context):
>
> $I0 = pio.'print'("sample data\n") # return sucess (>=0) or
> failure (<0)
> pio.'print'("sample data\n") # throw exception on failure
Oooh. Useful.
> * C<sockaddr> returns a string representing a socket address
> [Nicholas] "I don't think that this is appropriate. It's IPv4
> specific."
>
> A more general SocketAddr PMC seems to be needed here.
I think someone else said it too, but more a SocketAddr PMC hierarchy?
At least, a PMC class for each distinct way of describing addresses, that all
fulfil a SocketAddr role.
Nicholas Clark
