my $response=doSomething();

sub doSomething {
...
# fail
return 0;
}
[download]

In the real inherited programs as many as ten refs are passed to the subs. I could understand if they where all being changed, but often it is only the response which gets changed.
If I where writing from fresh I'd be with you on the return way of doing things. Thanks for confirming my feelings that this is just poor practice.

Such code smells like a C programmer who couldn't stand to program without memory pointers and grabed the first thing in Perl that looked anything like it. Screwing with pointers is perfectly acceptable in C, as most C programs are very concerned with efficiency. If you're using Perl, you're already giving up so much efficiency over pure C that you can usually ignore the passing style.

If more than one refernce is being changed, then Perl is perfectly capable of returning multiple values as a list instead. For instance:

my ($foo, $bar, $baz) = do_something();

sub do_something 
{
    return 1, 2, 3;
}
[download]

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Long term, functions shouldn't take 10 parameters (that's ugly even in C...structures are a good way to fix this), and in Perl named variables (through use of hashes) are a good way to fix this.

do_wacky_stuff(
  -alpha => 1,
  -delta => 'sputnik',
  -beta => 2,
  -gamma => 3,
);
[download]

Note order doesn't matter, and that's why it's cool. Use Params::Validate for added fun-ness.

Also you mentioned inherited code being the root of all your problems. Such is life! My handwritten-from-scratch code doesn't have any bugs! SCENE 42: flyingmoose is striken dead by a lightingbolt from the heavens, onlookers seem puzzled as he was indoors!

oming from a more formal (ADA, Java) background I would favour a return

Perl is as formal as you make it. I prefer to call those languages 'whiney' not 'formal'. Why? Well you can just as easily screw up a Java app, and it takes discipline no matter what you do. Other languages just want to hamper your productivity more than others :)

Typically this type of issue arises with programers and programs from other languages like C. In C you can return at most a single item from a function so such "pass a reference and have the sub change the referenced item" strategies are necessary when you need to return multiple items. Perl doesnt have these restrictions so this type of stuff is generally frowned apon and considered to be unperlish. And not only that, but perl has a funky (but poorly documented and explained IMO) mechanism for handling it when you do need those type of semantics.

First off in perl if we want to return several things:

  sub foo { return ('we','do','so') }
[download]

Second, if you want to an argument via reference semantics dont pass in a reference, instead let perl do it for you

  sub foo { $_[0]='foo' }
  my $x='bar';
  foo($x);
  print $x; #prints 'foo'
[download]

@_ is special in that it is an array of aliases to the original argument list. Altering members of the array will change the original values. But once the value is pop'ed or shift'ed off the array the aliasing is blown. For instance

  sub foo { my $x=shift; $x='foo'}
[download]

won't work the same as the earlier version that exploits aliasing.

Having said all of this, if you are aiming at converting C code into perl code then think about returning lists, and not modifying your subroutines arguments. I think youll find in the standard documentation some stuff to aid programmers from other backgrounds coming up to speed with perlish ways to do things.

Also, its worth considering that doSomething() isnt a popular style in the perl community for a variety of reasons. Generally most would lean towards do_something() instead. I certainly would.

Having said all of this, if you are aiming at converting C code into perl code then think about returning lists, and not modifying your subroutines arguments.

Additional advice to the question poster -- not having side-effects is the way in functional programming, it should be noted, and it is in general a great way to think, especially in Perl where many of us think pseudo-functionally. Returning lists (or hashes, which are just semi-magical lists) is incredibly slick, as you can do cool thinks like return:

{ -error => 1, -reason => 'magic', -newt => 'yes', -willgetbetter => '
+no' }
[download]

Instead of just '3'. This is sort of like returning a C-struct on the stack or a reference to a data-structure, but oh so much easier to use. Embrace the camel and it's funkiness, hold not onto the ways of C. You can code in Perl 'baby-talk' as we call it (that's not an insult, it's just the way new coders write) for a long while, but eventually, strive to be more Perlish, and it will reward you by making programming infinitely more fun and powerful.

my $response = doSomething();

sub doSomething {
   return 0;
}
[download]

will do it, but remember also that Perl returns the last computed value form a sub as well. So:

my $response = doSomething();

sub doSomething {
   my $response = 0;
}
[download]

My advice would be to explicitly return something from the sub rather than manipulating a variable which is outside the sub.

jdtoronto

Did you intend to hide the definition of my $response at the outer scope? Why not just place a 0; at the last line of the sub, rather than create a lexical only to have it read and destroyed immediately?

When you say "fails", do you mean "needs to return 0", or do you mean "throws an exception"? Because then this:

  my $response = doSomething ();

  sub doSomething {
    #..do something which fails
    0;
  }
[download]

  my $response = doSomething ();

  sub doSomething {
    eval
    {
      #..do something which fails
    };

    if ($@)
    {
      # handle the error
    }
    0;
  }
[download]

In addition to what other monks have said:

• Don't use mixed case style in variable and subroutine names. It is ugly and unreadable IMHO. Use all lowercase, and separate words with _ (underscore). However, if you're maintaining code, you may choose to stick with the existing convention. (s/doSomething/do_something/ - much better...)

• Use short, familiar names for short lived variables and long, descriptive names for long lived ones. Don't try to "compress" or "pack" many words or concepts into a cryptic, unspellable variable name. A few more keystrokes will save you many a headache two weeks later. Anyway, what does the "l" in $lResponce stand for?

  Besides, I think it should be the other way around: $response in the inner sub block, and $lxxxxx_response in the outer scope. (substitute lxxxxx with the answer to my previous question)

procedure doSomething ( lResponse out INTEGER ) is
begin

   -- ... do something that fails

   exception when others =>
        
      lResponse := 0;

end doSomething;
[download]