SPUG: Scope question

[Steve Howell]

----- Original Message -----
From: Peter Darley <pdarley at kinesis-cem.com>
>
> I agree, there is always room to improve ones coding techniques.  One
> reason that I want to use the globals is that I've gotten mixed results with
> passing around hash references and as hashes, and I'm not comfortable with
> my understanding of when elements of a hash are copied, when the elements of
> a copied hash are just references to the real contents of the hash, etc.  I
> figured it would be simpler to rely on globals to ensure that every time my
> session info hash gets used I know that it's the correct one.
>

If you're going to program in Perl for any length of time, then you need to
learn the difference between passing around hashes and passing around hash
references.

Fortunately, the rules are easy.  For example, if you pass a hashref to a
subroutine, then it has a ref to the "original" hash.  If you pass in a full
%hash to the subroutine, it's going to make a copy as soon as you do my (%args)
= @_;  The act of doing an array assignment makes the copy of the hash, so
you're no longer modifying the original.

Other rules apply, but even if you don't know the rules, or you forget the
rules, or you doubt my interpretation of them, you can always create small test
programs to verify your assumptions.  You will rarely be surprised.

Using globals does not protect you from ignorance about copy semantics.
Consider this code:

$ref = { apple => 'red' };
$copy = %$ref;
$copy{apple} = 'mac';
print $copy{apple};
print $ref->{apple};

You still need to consider where things are copied, and where things are ref'ed.

> I don't write OO Perl, as I don't see any particular value in it unless
> you're putting modules out into the wild.  I find it far easier to conceive
> of functions as being things that transform data, so I can have any number
> of functions that get data into a certain state before passing it off to
> another function.

Having well-conceived functions definitely makes sense.  Going to OO won't
magically make your code better organized, and if done poorly, it could even
make it worse.  Having said that, I think OO gets a bad knock sometimes.  It's
really not a radical departure from normal procedural code.

Say you have a procedural program that modifies employee data:

my $employee = { fname => 'Mary', lname => 'Lamb', salary => 150 };
giveEmployeeRaise($employee, 0.05);
renameEmployee($employee, lname => 'Wolf');
registerEmployeesDependents($employee, [ $child1, $child2, $child3 ]);

As your project grows, you might want to organize your code a little better, so
that all of the employee methods are in an Employee package:

my $employee = { fname => 'Mary', lname => 'Lamb', salary => 150 };
Employee::giveRaise($employee, 0.05);
Employee::rename($employee, lname => 'Wolf');
Employee::registerDependents($employee, [ $child1, $child2, $child3 ]);

After a while, it gets tedious to repeat "Employee" all over the place.  Perl
gives you a little syntatic sugar to avoid this:

my $employee = { fname => 'Mary', lname => 'Lamb', salary => 150 };
bless $employee, 'Employee';
$employee->giveRaise(0.05);
$employee->rename(lname => 'Wolf');
$employee->registerDependents([ $child1, $child2, $child3 ]);

All blessing does is tell Perl that the "default" package to find methods for
$employee is Employee.  It's that simple.  And it's not restrictive.  You could
still call other methods on $employee:

MyDebugger::DumpHashStructure($employee);
calculate_tax_for_employee($employee);

The OO syntax in Perl is very Perlish.  It's a bit ugly, and it's a bit
untraditional, but you get a lot more flexibility than from more strictly OO
languages.  Also, you can go as deep with it as you want to.  I've found the
deeper I go, the more I like it, so I hope you do too.












 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org