Re: Re: Returning a Junction

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

Comment on Re: Re: Returning a Junction

Replies are listed 'Best First'.
Re: Re: Re: Returning a Junction by diotalevi (Canon) on Sep 04, 2003 at 15:04 UTC
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]

Replies are listed 'Best First'.

Re: Re: Re: Returning a Junction
by diotalevi (Canon) on Sep 04, 2003 at 15:04 UTC

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]