develooper Front page | perl.perl5.porters | Postings from August 2011

Predeclaration vs. scalar types - no worries

Thread Next
From:
Chip Salzenberg
Date:
August 12, 2011 14:11
Subject:
Predeclaration vs. scalar types - no worries
Message ID:
CANSL5VH64cQOfQ9L++UO1hofT_xyBkZWnWc4ZuDxKu6L6p4B6g@mail.gmail.com
Jan asks:
> How is this "change semantics when you pre-declare" going to work for
internal operations like copying scalars?

At the XS level, this is an incompatibility, but only a VERY TINY one that
is even noticeable in almost no code and doesn't malfunction in evil ways
when it does arise; so we can just document it and carry on.  No need for
zones of predeclaration or anything like that.  We're taking advantage of
the Perl's API abstraction (such as it is).

The TINY incompatibility is this:
   OLD: SvPOK() is true whenever the value was either semantically a string
or had been incidentally stringified.
   NEW: SvPOK() is true in all the same circumstances, *except* incidental
stringification of an IV, UV, or NV.
   UNCHANGED:  Everything else, including SvPOKp() being true after
incidental stringification, and the return values of SvPV() and family.
This sounds like it might be trouble, but it really isn't.  Think about it.

The only code in the core that even noticed was some really bad hackery in
Data::Dumper, and the fix was trivial and backward-compatible.

That's it.  Since SvPV() and company still work the same, if you coded to
get a string you can still get it.  And if you really care about whether
SvPVX() is valid, then the test is still the same as it used to be:
SvPOKp().  So no change there either.

In short: We can just do it.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About