Is there a way to force "typecheck" to work for non-overload cases?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Is there a way to force "typecheck" to work for non-overload cases?

Myria
Is there a way to force "typecheck" to be used for function arguments
on functions that aren't overloaded?  Currently, SWIG silently ignores
typecheck specifications when dealing with functions that aren't
overloaded.

Essentially, I want to inject custom code into the validation process
for deciding whether a parameter's type matches.

This is different from %typemap(check), because the type conversion
may not actually be possible.

Thanks,

Melissa

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is there a way to force "typecheck" to work for non-overload cases?

William S Fulton
On 11 October 2016 at 20:53, Myria <[hidden email]> wrote:

> Is there a way to force "typecheck" to be used for function arguments
> on functions that aren't overloaded?  Currently, SWIG silently ignores
> typecheck specifications when dealing with functions that aren't
> overloaded.
>
> Essentially, I want to inject custom code into the validation process
> for deciding whether a parameter's type matches.
>
> This is different from %typemap(check), because the type conversion
> may not actually be possible.
>
The "typecheck" typemap is designed explicitly for method overloading
only, see http://swig.org/Doc3.0/Typemaps.html#Typemaps_overloading.

You could hijack the arginit typemap to do the validation you require.
Why not just supply your own "in" typemaps to add in your
customizations? Also, I am not sure what sort of checks you can do
before converting the type into C/C++ and what the point is because
the "in" typemap usually does whatever checking is required.

William

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is there a way to force "typecheck" to work for non-overload cases?

Myria
I have a "vector3" class representing a vector in 3-space.  I have
various C++ functions that take vector3s, and want to call them from
Lua.  The problem is that I would like to also support calling a
function expecting a vector3 with a standard Lua table of three
elements, such that both these cases work from Lua:

-- With an actual vector3 object
v = new_vector3()
v.x = 1.2
v.y = 3.4
v.z = -5.6
SomeFunction(v)

-- With an ordinary Lua table
SomeFunction({ 1.2, 3.4, -5.6 })

Thanks,

Melissa

On Sat, Oct 22, 2016 at 11:46 AM, William S Fulton
<[hidden email]> wrote:

> On 11 October 2016 at 20:53, Myria <[hidden email]> wrote:
>> Is there a way to force "typecheck" to be used for function arguments
>> on functions that aren't overloaded?  Currently, SWIG silently ignores
>> typecheck specifications when dealing with functions that aren't
>> overloaded.
>>
>> Essentially, I want to inject custom code into the validation process
>> for deciding whether a parameter's type matches.
>>
>> This is different from %typemap(check), because the type conversion
>> may not actually be possible.
>>
> The "typecheck" typemap is designed explicitly for method overloading
> only, see http://swig.org/Doc3.0/Typemaps.html#Typemaps_overloading.
>
> You could hijack the arginit typemap to do the validation you require.
> Why not just supply your own "in" typemaps to add in your
> customizations? Also, I am not sure what sort of checks you can do
> before converting the type into C/C++ and what the point is because
> the "in" typemap usually does whatever checking is required.
>
> William

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is there a way to force "typecheck" to work for non-overload cases?

William S Fulton
You need to write an "in" typemap specific to vector3 pointers,
references etc that does this conversion. if the conversion from the
wrapped vector3 type fails, then try to convert from a Lua table in
your typemap code.

William

On 22 October 2016 at 20:09, Myria <[hidden email]> wrote:

> I have a "vector3" class representing a vector in 3-space.  I have
> various C++ functions that take vector3s, and want to call them from
> Lua.  The problem is that I would like to also support calling a
> function expecting a vector3 with a standard Lua table of three
> elements, such that both these cases work from Lua:
>
> -- With an actual vector3 object
> v = new_vector3()
> v.x = 1.2
> v.y = 3.4
> v.z = -5.6
> SomeFunction(v)
>
> -- With an ordinary Lua table
> SomeFunction({ 1.2, 3.4, -5.6 })
>
> Thanks,
>
> Melissa
>
> On Sat, Oct 22, 2016 at 11:46 AM, William S Fulton
> <[hidden email]> wrote:
>> On 11 October 2016 at 20:53, Myria <[hidden email]> wrote:
>>> Is there a way to force "typecheck" to be used for function arguments
>>> on functions that aren't overloaded?  Currently, SWIG silently ignores
>>> typecheck specifications when dealing with functions that aren't
>>> overloaded.
>>>
>>> Essentially, I want to inject custom code into the validation process
>>> for deciding whether a parameter's type matches.
>>>
>>> This is different from %typemap(check), because the type conversion
>>> may not actually be possible.
>>>
>> The "typecheck" typemap is designed explicitly for method overloading
>> only, see http://swig.org/Doc3.0/Typemaps.html#Typemaps_overloading.
>>
>> You could hijack the arginit typemap to do the validation you require.
>> Why not just supply your own "in" typemaps to add in your
>> customizations? Also, I am not sure what sort of checks you can do
>> before converting the type into C/C++ and what the point is because
>> the "in" typemap usually does whatever checking is required.
>>
>> William

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Loading...