On Tuesday, Sep 30, 2003, at 19:31 Europe/Berlin, Melvin Smith wrote:
Since PIO_parse_open_flags just assists the IO code in fulfilling an API, but is not part of the published API, I would suggest that it be moved into the private, but before tests are written for it, there should be a spec written.
Given how much code is already written, it's probably most efficient to write the spec as tests.
When I wrote the code, there was not even a design for what sort of API we would implement. I chose supporting a "stringified flags" because I liked it, but there was never much discussion about whether this was the right way or not. It is a very Perlish way of doing it, but languages that have constant values would then have to translate back to the string version to run on top of Parrot. That, or there will need to be a second form of open() written to take numerical constants.
When I was writing the PIO_parse_open_flags() test it did seem to me rather Perlish to have string flags in the first place. But I'm a new cockroach in town, so I kept my mouth shut, not wanting to get stomped on.
If the PIO_F_* flags used by open() were moved up to io.h then they could be exported as .constants by config/gen/parrot_include.pl and used explicitly.
Various composite flags could be added for convenience.
PIO_F_WRITE_TRUNC (">")
PIO_F_WRITE_APPEND (">>")
PIO_F_READ_WRITE ("+<", "+>")Also, add an INT flag version of open.
inline op open(out PMC, in STR, in INT)
In short, I think it should be discussed as to whether it is even the right way. It seemed right at the time, but now I'm having second thoughts.
-Melvin
