Any way to tell if a scalar is a string?

[C.DeRykus]

  >> Quoth Sir Robert Burbridge <[email protected]>:
  >>
  >> > On 12/09/2009 07:52 PM, Ben Morrow wrote:
  >>
  >> > > Don't ever check for class membership with 'ref'. In fact, most uses of
  >> > > 'ref' except as a boolean are bugs. The correct way to check for class
  >> > > membership is to call the ->isa method; if you aren't sure something is
  >> > > an object, you can use Scalar::Util::blessed or wrap it in an eval {}.
  >>
  >> > Out of curiosity, why "Don't ever check for class membership with
  >> > 'ref'"?  Do you mean, "... unless you want to exclude subclassed
  >> > objects", or is there some more dire problem with it that I don't see...
  >>
  >> Consider
  >>
  >>     ref bless [], "HASH";
  >>     ref bless [], "0";
  >>
  >> for why one of reftype or blessed from Scalar::Util is better, depending
  >> on what you meant.
  >> ...

  CD> Aren't 'ref' and 'blessed' equally confusing here...am I
  CD> missing something?

  CD> perl -wle "use Scalar::Util 'blessed';$o=bless [],'HASH';
  CD> print blessed $o;print ref $o"

  CD> HASH
  CD> HASH

but you know what function you called and can interpret the results
accordingly. $o is blessed into 'HASH' and is also a HASH ref. nothing
confusing there to me. actually reftype would be a better call there as
ref is returning the class, not the type.

Um, I was confused about the earlier recommendation not to use
ref as a generic check for class membership. And, IIUC, a 'ref'
might be returning a builtin type (or even in a very weird case
bless [], 'HASH' -> a package that looks like a builtin type);
whereas, Scalar::Util's blessed reports only a package.

 

[Peter J. Holzer]

I have to disagree. I've worked with packstrings similar to:

'I/i I/(a10) I/i'

and, as I've mentioned in an earlier post, there's no way for me to
necessarily know where the first set (of integers) ends and the second
set (of text) begins and ends, especially if all the text strings in
the second set all happen to look like integers.

I'm missing something in this discussion:

Except for some simple data munging (transfer some data from a flat file
to a databases, for example) you need to know what the data *is* to
process it properly. And by "what it is" I don't mean "an integer" or "a
string", but things like "a credit card number", "a part number", "the
length of the vehicle in meters", "the number of life kangaroos exported
from Australia in 2007".

Once you know that you also know what kind of operation makes sense on
the data (e.g., even though a part number is "a number", it doesn't make
sense to add two part numbers) and the actual representation (is it a
string, an integer, a floating point number, a bit-packed structure?)
becomes secondary or is implicit.

So if you have a pack string like 'I/i I/(a10) I/i' you don't just need
to know that 1st and 3rd thing are unsigned integers, you also need to
know that the 1st one is a count of items, while the 3rd one is a
product class, to process them properly.

hp