API design issues (wrt parallel and otherwise)

[Eric Wilhelm]

This is an attempt to collect all of the issues regarding 
parallel/non-blocking subclasses into one place.  Some of this 
is "subclasses in general", some of it is specifically to do with 
non-blocking or parallel and/or "output not console."  It is incomplete 
and glosses over some things, but I'm trying to be brief, so I'll 
preface no more other than to say that the state of things at present 
is a result of Andy's valiant efforts and I think he's just taking a 
swing at "what might work" in some cases.  In short, these are issues 
that I think need love, work, and possibly discussion.


Too much is being built-in to the API specifically to support Parallel, 
(i.e. too specifically.)  What TAP::Harness needs is support for 
subclasses (which might need parallel and/or nonblocking iterators.)

TAP/Formatter/Console.pm
  * shouldn't know about jobs()
    (needs a different mechanism to pick a $class)

  my $class
    = $self->jobs > 1
    ? 'TAP::Formatter::Console::ParallelSession'
    : 'TAP::Formatter::Console::Session';


TAP/Harness.pm
  * too much awareness (don't need jobs() as a stub/~virtual method)

  $formatter_args{jobs} = $self->jobs;
  $self->formatter(
      TAP::Formatter::Console->new( \%formatter_args ) );

TAP/Formatter/Console/ParallelSession.pm
  * should be in the TAP::Harness::Parallel distro

  * still seems like too much code (i.e. a lot of "borrowed logic")

TAP/Parser/Iterator/Process.pm
  * this may need to be unwound, probably at compile-time or something
    (maybe another class -- see below)  The can_read() call needs to be
    $self->can_read(0) to be non-blocking

    sub next_raw {
      ...
      if ( my $out = $self->{out} ) {
        if ( my $sel = $self->{sel} ) {
          my $err  = $self->{err};
          my $flip = 0;
          while ( my @ready = $sel->can_read() ) {

TAP/Harness/Parallel.pm
  * this seems really wrong that the parser stash handles the result
    (isn't the harness the thing deciding what to do next?)

    $parser->stash->result($result);

  * nonblocking:
    * the parser needs a next_nonblock() which returns zero
      for continue and undef for done
    * the iterator needs a next_raw_nonblock() (or another class)
    * I *think* it is ok for the parser to poke the iterator, then
      return zero if it isn't ready or a result if it is

TAP/Parser.pm
  * I think the above would be implemented externally to _iter()

--Eric
-- 
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------