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. 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.
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
Juergen Boemmels <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/30/2003 01:20 PM
To: Michael Scott <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: PIO tests
Michael Scott <[EMAIL PROTECTED]> writes:
> On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels
> wrote:
>
>
> > Michael Scott <[EMAIL PROTECTED]> writes:
> >
> >> Here are some tests for the io.h API that should go in t/src/io.t.
> >
> > Ah yes. I know I submitted one too. I thought it got committed a long
> > time ago but maybe it wasn't. I will try to merge it with your tests
> > and commit a change.
> >
> > In one test you include "../io/io_private.h". I'm not sure if it's a
> > good idea to test implementation details. On one side its better to
> > test as many as you can, on the other side mainly the public API
> > should be tested, the implementation should just work.
>
> I'm just including io_private.h to get the correct flags to test the
> return values of PIO_parse_open_flags() which is in the public API.
Maybe PIO_parse_open_flags should also get moved to io_private.h. The
private/public split of the io subsystem is far from complete. In fact
io is the first subsystem that even tries to do so.
> I agree there are limits to what should be tested, but what embarked
> me on the tests in src/io.t was the failure of test 6 in pmc/io.t. I
> tried to fix it, but because there were no src/io.t tests I couldn't
> be sure whether the problem lay in the io.ops code or the io/* code.
>
>
> Needless to say, once I'd written src/io.t, I got sidetracked into the
> need for string C code tests, and never got back to pmc/io.t.
>
>
> It seems to me that there are at various levels of "public" in Parrot,
> and each one should be tested. Furthermore, the more tightly the
> testing is done at the lowest level, the more confident we can be
> about the higher level test results.
Ok you convinced me, we need to test private implementation
details. But this tests should be cleanly flagged as such.
> PIO_parse_open_flags() is, I think, a good case in point. It makes
> sense to throw a bunch of invalid values at it in src/io.t, and then
> assume that it works in pmc/io.t.
>
>
> BTW those src/io.t tests should be rewritten to use the scheme Leo
> uses in the 3rd test in src/basic.t. I proposed a patch to simplify
> this in "[PATCH] C code test header" which if you could get into CVS
> I'd be grateful as my string tests will rely on it.
The whole c_output_is() tests are more or less a hack.
Ideally there would be C-markos like
OK(val, name), DIAG(text), IS(this, that, name), etc. and be able to
check individual c-statements without recompiling and running a new
file each time.
bye
boe
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel:
++49-(0)631-205-2817
Universitaet Kaiserslautern Fax:
++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
