Deb wrote:
> This (code below) makes sense to me, but I was talking this over with a
> co-worker on Friday, and then I tried putting together some 2-dimensional
> hashes - which hurts my head at the moment.
Hi Deb
Actually, the hash hee--so far, anyway--is not two-dimensional. More later
> So I went to
> perl.plover.com/FAQs to read (again) his article on references, and I still
> have a mental block. Conceptually I understand multi-dimensioned hashes, but
> in practice I have a LOT of trouble with the syntax.
I probably should have named the reference inside getRelationship $relationshipRef
rather than just $relationships, since that would better have reflected the
relationship to the original structure.
It will help to make some distinctions between 2D referencing and argument passing.
One of the shortcomings of perlref.pod is that it focuses too narrowly on the role of
references in building multidimensional structures, and too little on thier role in
allowing subroutines to modify protected data. I believe strongly in the principle of
data encapsulation--that leaving variables visible in the global or script-level
namespace is a recipe for confusion.
Since the default behavior for a parameter is to pass by value, subs normally have
read-only access to the arguments passed in. Passing in by reference provides a
work-around, but at the price of indirection. It is still pass-by-value, but the
value being passed is essentially the key giving access to the data being referenced.
That's why these references have such a kludgy look.
The line where this hash reference is used:
if (s/^x\s+//) {$$relationships{$key} = $_;}
could also be written, and perhaps more clearly:
if (s/^x\s+//) {$($relationships){$key} = $_;}
To indicate the real process and precedence taking place.
When the function is called:
getRelationship($string, \%relationships);
The syntax of the second parameter does a little embedded work, equivalent to:
my $hashRef = \( %releationships );
getRelationship($string, $hashRef);
so that, right now, $hashRef is a single scalar value POINTING AT %releationships
Thus, when this reference is accessed inside the function [as the scalar
$releationships], it must be dereferenced. It is essentially equivalent to the
alphanumeric portion of the %relationships hash originally referenced. Therefore, to
recover access to the original data, the same syntaxes used on the name would be
applied here:
%($relationships) or %$relationships would represent the original hash as a whole.
Any element of the hash would likewise be referenced by usning the pointer, and adding
the appropriate variable identifier operators to the name:
$($relationships){$key} <==> ($relationships)->{$key} <==> $$relationships{$key}
> I need to work hard to solidify how to put it together in a real coded
> situation.
In the test stub represented by the testGetRelationships function, we load only one
element of the original %relationships hash. Using a hash here actuall assumes that
the keys--the first elements of each line, are unique. If so, then you could simply
iterate through the @Array containining the lines, calling the function for each line.
When the loop finishes, the relationship hash should be loaded with all the
relationships.
If those left elements are not unique keys, you probably will have to use a 2D
structure. The outer dimension of this structure would be grouping by disinct key,
the inner dimension would be any array of all the command parameters found for that
key. Although the outer structure would call for a hash, the inner structure would
probably require only an array..
Since it is now 2:23 am here in Oregon, I'm a bit too groggy to attempt an example of
that right now, but I will give it a shot tomorrow, when I am more cogent.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
