George Schlossnagle <[EMAIL PROTECTED]> writes:
>
>So what I have going on is that I have data I'm passing in and out of
>another language (PHP, specifically), and I'm holding it in either
>opaque types (if it's an object or has discernible magic), or
>converting into a native type. What I have here is that I have some
>Perl data that's being passed into PHP, which then internally calls
>back up to Perl to use it. This data certainly looks like normal
>character data, but it's marked PVMG. Using an opaque type for this
>data is more inconvenient than it might sound, since PHP's auto-
>casting functions (cast me to a string/cast me to an int, etc.)
>aren't terribly rich. Besides handling utf-8 data (which I both
>think is probably the case here, as well as a general lost-cause
>until php 5.2), do you see any inherent risks in downcasting this SVs
>when making them available in PHP?
What has worked reasonably well in perl/Tk's faking of Tcl is logic like:
if (SvRV to SvOBJECT)
- fake a "handle" to the object if target has the concept
or just stringify and hope object does right thing...
if (SvRV to SvTYPE >= SVt_PVAV)
- data structures - does target have lists / associatve arrays?
elsif SvIOK
- convert to int
elsif SvNOK
- convert to double
else
- its a string - convert to targets representation/encoding
Almost all this is based on Sv?OK flags and "type" is only used for
(references to) ARRAY/HASH/CODE/GLOB boundary cases.
>
>Basically I have:
>
>($perlscalar) = $dbi->fetch();
># perlscalar is now magical, probably utf-8, but basically just a
>char * of some sort
>$php->someFunction($perlscalar);
>
>and then in PHP
>
>function someFunction($sv) {
> // I'd like $sv to be a string here, as opposed to a scalar I need
>to cast as a string
So just call SvPV_xxx() to get char */STRLEN
and then build the right thing from those.
