Re: [Swig-user] perl5: function wrappers can't see through the magic of global variables?

[Josh C. <jc...@nc...>]

On Mon, 17 Dec 2007, Dustin J. Mitchell wrote:

> On Dec 16, 2007 4:51 PM, William S Fulton <ws...@fu...> wrote:
>> Okay, I've backed out the change until a better patch comes along.
>
> What if SWIG_AsCharPtrAndSize looked like this?
>
>  if (SvPOK()) {
>    /* existing stuff */
>    return SWIG_OK;
>  }
>
>  if (SWIG_ConvertPtr(..)) {
>    /* existing stuff */
>    return SWIG_OK;
>  }
>
>  if (SvOK()) {
>    /* same PV conversion stuff as in first if block */
>    return SWIG_OK;
>  }
>
>  return SWIG_TypeError;
>
> Josh -- I think that would address your objections?

It addresses the objection about the treatment of a wrapped char*.  It 
doesn't address the point about other things becoming acceptable as char* 
arguments, which I now realize has broader implications than what I 
mentioned (see below).  Also, I'm not sure why the "if (SvPOK())" part is 
there, though perhaps it makes things more efficient.

As discussed in my earlier email, the original patch allowed things like 
wrapped int* and proxy class instances to be passed for char* arguments. 
The modified patch would (it seems to me) still allow that.  Another 
important change in behavior is that formerly an integer could not be 
passed for a char*, but with the patches it can be passed (it is converted 
to a string representation).  So, for example, aa::print_str(42) would 
fail without the patch, but succeeds with it, printing "42" 
(aa::print_str('42'), in contrast, works even without the patch).

Arguably these changes are all good, or at least Perlish.  Apparently Perl 
allows all of these things to be turned into strings implicitly, so maybe 
SWIG-generated modules should allow them to be used as char* arguments. 
This would be a significant change, though, and I wouldn't want it to slip 
in unnoticed.

I've never been clear on to what extent Perl maintains a distinction 
between different scalar types, or what SWIG does about this and whether 
this is appropriate.  There is perhaps a clash between C/C++ typing and 
Perl's making all scalars in some sense the same data type.  Perl will 
happily convert a string like "foo" to an integer (0) in "integer 
context".  I've always considered this a misfeature, but that's Perl's 
policy.  Currently, SWIG deviates from this: passing "foo" when an int is 
required yields a type error.  Should that be changed?  There is also the 
question of overload dispatch, which should be kept consistent with 
changes to "in" typemaps (you might find that, even with your patch, you 
can't pass the problematic arguments to overloaded functions).  There was 
a big change to Perl dispatch handling a couple of years ago due to 
related issues (integers would be turned into floats if you did arithmetic 
on them, and overload dispatch would not accept floats for int arguments).

I'm not trying to be obstructionist.  I'd just like to see these issues 
addressed consistently and correctly.

Josh