in reply to Re^4: ref eq "REF"
in thread ref == "REF"

Sorry, I'm lost. Either I'm not understanding you, or you're not understanding me, or most likely both :)

The function ref is used to determine if its argument is a reference: if ref returns a true value, then its argument is a reference to something, right?

As an added bonus, it tells you what that reference is referring to. Therefore the following code makes everyone happy, right? 

#!perl -l
my $s = "foo";        # a scalar
print ref($s);        # prints nothing: $s is a scalar, not a ref
my $sr = \$s;         # a reference to a scalar
print ref($sr);       # prints SCALAR
my %h;                # a hash
print ref(%h);        # prints nothing: %h is a hash, not a ref
my $hr = \%h;         # a reference to a hash
print ref($hr);       # prints HASH
my $hrr = \$hr;       # a reference to a reference to a hash
print ref($hrr);      # prints REF

[download]

So the precise meaning of REF is "a reference to a reference (to anything - sorry, it only goes one level deep)"

--
edan

Replies are listed 'Best First'.
Re^6: ref eq "REF"
by gaal (Parson) on Oct 18, 2004 at 15:53 UTC
    Fine; where would you find this useful? (Viz, with added value over SCALAR, which up till today I'd have interpreted as "(reference to) a scalar value, which might be a number, a string, or a reference" (inclusive or here).

    My problem arises from a seeming inconsistency of the concept "scalar" in Perl. In the guts, there are IVs and NVs and PVs and RVs; but the user just wants his $scalar, with all these possible values conflated. I'd venture to say that this conflation is a widely accepted feature by Perl programmers. Note how another, well-known breach of this generalization — you can't use references as hash keys — is often regarded as suprising (and frustrating) behavior the first time someone encounters it (I think!). Certainly from the user perspective, of the Perl language, it isn't a useful feature, but presumably it makes more sense from the implementation, perl, point of view.

    So is ref returning REF on \\"moose" just some leftover hairiness? Or is there a nice hack waiting to be found here?

[reply]
[d/l]
      another, well-known breach of this generalization — you can't use references as hash keys

      This is a different issue. Hash keys are not scalar values, they are string values. It happens that, very often, the stringified value is the same as the useful scalar value. In some cases, though, this is not true. References are one example, but another would be a variable with a dual value. Consider the following example:

          open "non_existent_file";
    print $!+0, ": ", $!;
    $hash{$!}++;
    for (keys %hash) {
      print $_+0, ": ", $_;
    }

      [download]

      Which outputs the following:

          2: No such file or directory
    0: No such file or directory

      [download]

      The separate numerical value is lost, because the value is stringified as the hash key, not stored as an arbitrary scalar.

[reply]
[d/l]
[select]
        I don't see it as a different issue at all: in fact, this is exactly my point about the internals showing!

        Hash keys accept only string values because it was a lowercase-p-perl design decision to make them string values. This didn't have to be the case! Trading off efficiency, hv_store and friends could have accepted RVs as well. The dual value issue you raise is indeed different, and more vexing in this case, because if you were to use a multi-valued SV as a hash key, confusion would probably arise about which value you wanted to be definitive (or if you wanted to require subsequent SVs to have *both* values determine the lookup). This is not a problem with references as keys.

[reply]
[d/l]

In Section Seekers of Perl Wisdom