Python and default values

Hello,
I have this set of c++ functions:

void set_shader_input(InternalName *id, double n1, double n2, double n3, double n4, int priority=0);
void set_shader_input(InternalName *id, double n1, double n2, double n3, int priority=0);
void set_shader_input(InternalName *id, double n1, double n2, int priority=0);
void set_shader_input(InternalName *id, double n1, int priority=0);

and I have problem with calling (for example) this:

teapot.setShaderInput("Inputs.num4",1.0,0.0,1.0,1.0)

as, because of the default value given to priority, python believes I am calling :

void set_shader_input(InternalName *id, double n1, double n2, double n3, int priority=0);

instead of:

void set_shader_input(InternalName *id, double n1, double n2, double n3, double n4, int priority=0);

Is there a solution that doesn’t get rid of the priority default value?

Thanks

Hmm, that is unfortunate.

You can certainly add the explicit priority value, e.g.:

teapot.setShaderInput("Inputs.num4",1.0,0.0,1.0,1.0, 0)

David

mmh… yes I could, but either if I leave it this way or I get rid or the default value, it’s not going to be backward compatible any more…

Probably I should just get rid of:

void set_shader_input(InternalName *id, double n1, double n2, double n3, int priority=0);
void set_shader_input(InternalName *id, double n1, double n2, int priority=0); 

Yeah, probably a good idea. This is the same reason that NodePath::set_bin() does not accept a default value for the sort parameter.

David

When I started this project I wondered why that functions where missing… and now I know there was reason. Awesome :slight_smile:

Btw is there any particular reason for having set_shader_input as a member of ShaderAttrib?

How else would you construct a ShaderAttrib with the appropriate inputs? Or do you have a different design in mind?

David

Sorry I wasn’t clear. I noticed that only ShaderAttrib::set_shader_input(ShaderInput*) is called in NodePath, but ShaderAttrib has also set_shader_input(Vec4,…) etc, and I was wondering if it is worthed to have them as member of ShaderAttrib.

Not a big deal actually but, considering I have added around thirty flavours of set_shader_input ( 15 times 2 as it takes string or InternalName), it would be better do not have all this code if it is useless

Ah, I see. The other flavors of set_shader_input() are just convenience functions on the primary interface. But the NodePath::set_shader_input() method is also a set of convenience functions on the primary interface.

I don’t see any reason to duplicate the convenience functions twice. Leaving them on NodePath should be sufficient.

David

Ok, that’s what I thought. Having only ShaderAttrib::set_shader_input(ShaderInput*) and the complete interface only in NodePath should be enough.

Thanks
Federico