Re: OO design: returning string and/or special value

[stevieb]

You don't specify exactly what "special" is. That makes it difficult to come up with a solution to the return value.

You also don't give an example of the subroutine in question. Does it accept parameters? If so, what type?

You could demand that a user send in nothing to get a string return, and if the user sends in a reference to something, you could generate data within the reference for something "special".

That, or require a hash as arguments: $o->method(want => 'special');, whereby if no args are present, you return a string.

More information is necessary that describes what you're doing in behind the scenes, why you want to return different types of information and an example of what you have now.

[wanna_code_perl]

Hi stevieb! Thanks for your input. Answers to most of your questions:

You don't specify exactly what "special" is.

See first paragraph of the OP. special is also a scalar, just a different application-specific format. It's possible to programmatically convert special to string, but not vice-versa. Said formats are well-understood in my problem domain, and complex enough to take several paragraphs to explain and justify, so I opted not to, trusting my fellow monks would trust me to accurately represent my underlying requirements.

I did give examples of the subroutine, and those examples did not accept arguments. That was accurate.

You could demand that a user send in nothing to get a string return, and if the user sends in a reference to something, you could generate data within the reference for something "special".

That, or require a hash as arguments: $o->method(want => 'special');, whereby if no args are present, you return a string.

These are reasonable suggestions. The second one, I almost went with, but then thought the list context idea was superior, especially when you remember the caller sometimes needs both the string and special formats, so you'd need want => 'both' as well, or something to that effect.

More information is necessary that describes what you're doing in behind the scenes, why you want to return different types of information and an example of what you have now.

I'm returning differing string formats because that's the way my particular problem domain works, and what the requirements demand. Callers will normally (95%) want the simplified string representation, but will sometimes want the more complex special format, and sometimes want both.

I'm sorry I wasn't as concrete as you would like. What follows is the most reasonable minimal example I can come up with. It mimics my current calling conventions and return types, and that's about all I can reasonably demonstrate. The relevant parts of the real class are about 800 lines worth of proprietary algorithm that I can't share without breaking an MNDA, even if you wanted to wade through it, which I wouldn't recommend. :-)

use Test::More;

package Foo {
    sub new     { bless { }, shift };

    sub method  {
        my ($self, $arg) = @_;
        # Network operation followed by internal processing, but
        # for the sake of example, say we've already done all
        # that and it's in $arg. (Normally method takes no args,
        # and is non-idempotent):

        wantarray ? (_special_to_string($arg), $arg)
                  :  _special_to_string($arg);
    }

    sub _special_to_string {
        # Really requires 100-odd lines of transformation code,
        # split among several other internal subs, but for now:
        lc(shift);
    }
}

my $arg = 'Really Special';

my $foo = Foo->new;
is scalar $foo->method($arg), lc($arg), 'explicit scalar context';
my $string = $foo->method($arg);
is $string, lc($arg), 'scalar assignment';

my ($plain, $special) = $foo->method($arg);
is_deeply [ $foo->method($arg) ], [ lc($arg), $arg ], 'list';

__END__
ok 1 - explicit scalar context
ok 2 - scalar assignment
ok 3 - list