develooper Front page | perl.perl5.porters | Postings from August 2008

Re: Iterator::Diamond (Was: Re: Fighting the Good Fight againstspam deluge)

Thread Previous | Thread Next
Aristotle Pagaltzis
August 3, 2008 04:43
Re: Iterator::Diamond (Was: Re: Fighting the Good Fight againstspam deluge)
Message ID:
* Johan Vromans <> [2008-08-02 21:55]:
>   my $input = Iterator::Files->new( files => \@filelist );
> chromatic <> writes:
> > Creating a new API in 2008 which requires the localization of
> > a magic global to do something obvious seems wrong to me.
> The question remains to what level it must be compatible with
> the current <> implementation. When a file list is passed, I'd
> say that @ARGV should remain untouched. But should ARGV, $ARGV
> and ARGVOUT still reflect the status of the iterator, as they
> do with <> ?

See that snippet above? You’ve got an `$input` after constructing
the object. It can have all sorts of methods – including a
complete set of accessors that would give you the same
information as `@ARGV`, `ARGV`, `$ARGV` etc would give you if you
were using the diamond operator.

So instead of having to localise `*ARGV` before I even look at
the variables the wrong way, use eg. `$input->name` in place of
`$ARGV`. That way, you there is by definition no possible
interaction when temporally nested scopes both want to iterate
over the records in a list of files, as long as each of them has
its own lexical variable to store the iterator in.

OK, so if you localise your globals vigilantly, you get the same
ability. Let’s skip over the fact that everyone forgets to do it
one time or other and then gets a weird bug.

But this also lets you easily iterate over the records within two
differents sets of files *within the same* scope. That is, I
think, also possible using globals… but I honestly don’t want to
be the one who writes that code. Or ever has to look at it.

For that reason, the base implementation should involve no
globals whatsoever.

However, …

* Tom Christiansen <> [2008-08-02 23:45]:
> My hunch, and it is only a hunch not a conviction, is that
> near-tranparent backwards compatibility is the only way to win
> over folks doing the various map{}@ARGV transformations in
> their day-to-day programming.  I know I'm far from the only
> one, as we've seen.  

… that sure is desirable.

And in one of his previous postings, Johan accidentally wrote
Iterator::Diamond where he meant Iterator::Files.

Therein, in my opinion, lies the resolution: there is no reason
that this can’t be written such that there’s a basic file
iterator class that uses proper abstraction, plus another that
derives from it but also emulates all the corresponding diamond
operator behaviour.

Ideally, then, you could also change the underlying class on a
case-by-case basis; in one case I might want a file record
iterator that uses 2-arg-open semantics and in another an
iterator that uses 3-arg open, but all the `*ARGV` emulation is
the same either way.

(So the modern view of Iterator::Diamond is a role not subclass.)

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About