Front page | perl.perl5.porters |
Postings from August 2011
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