in reply to Returning a Junction

That'd be improper. It is a perfectly sane thing for the module user to get back the list of useable cards and not for use in a boolean test. If you want to do a boolean test then the user should create the disjunction. Heck, do that right now in p5 if all you want is some equality tests: eqany().

if ( eqany( 'foo', available_cards() ) ) { ... 

sub eqany { $_[0] eq $_ && return 1 for $_[1] .. $_[$#_]; 0 }

[download]

Replies are listed 'Best First'.
Re: Re: Returning a Junction
by pdcawley (Hermit) on Sep 04, 2003 at 07:17 UTC
    Looks like a job for context to me. Return a list of cardnames in a list context and a junction otherwise.
[reply]
Re: Re: Returning a Junction
by hardburn (Abbot) on Sep 04, 2003 at 13:45 UTC

    Your solution isn't transparent to the end user. With a junction, the module simply returns the junction and the end user doesn't have to care--they test equality against a string they expected the module to return and nothing more needs to be done. No current code needs to be changed.

    Anyway, I just thought it was a cool use of a feature that isn't practical to use yet . . .

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

[reply]

      Ah, see I thought that *your* solution wasn't transparent because it hides the list behind a junction. If the person wants to read the list then s/he would have to query the result's eigenvalues (to borrow from Q::S's function. I don't know the p6ism for that). I regard that as distinctly unfriendly. I'm mulling over whether PDCawley's context idea would be a good idea - in scalar return a junction, in list return the list. Under p5 I'd rather return an array reference but that may just be habit.

[reply]

In Section Meditations