[Bf-python] Object types as string
Willian Padovani Germano
wgermano at superig.com.br
Wed Apr 4 19:09:31 CEST 2007
Stephen Swaney wrote:
> On Wed, Apr 04, 2007 at 03:13:42PM +1000, Campbell Barton wrote:
>> Hi, just wondering if were ok about ob.type's being a string..
>>
>> bpy.ipos.new('name', 'Material') # new material ipo
>> ob.type == 'Mesh'
>
> Funny you should mention this. I was just thinking about it the
> other day.
>
> As a general rule, we would like to get away from passing strings
> as arguments and use constants instead.
This is really something we should consider now carefully. There are
advantages to both sides.
> We talked about constants a little bit at the last meeting.
And we still didn't agree on what will be done, so it's important to
discuss this more, specifically: string constants vs. non string constants.
>>From a user perspective, constants have the advantage of being checked
> at 'compile' time rather than when the script is running. The can
> also be handled programmatically rather then being hard coded as
> 'magic numbers'.
>
>>From a C programming standpoint, constants can be used in case
> statements rather than the long if/else blocks you need with strings
> names.
Yes, Stephen covered the pros towards non string constants.
Now what would be good about string constants:
- If our constants (where possible, everywhere?) are strings, users can
choose to either write the strings directly or the constants. Both ways
are readable, strings are shorter: scene.objects.new('Empty') and we
still have the constants so users can check all available types.
- Ken pointed months ago that he disliked how a user could write correct
scripts using totally wrong constants, because internally their (int)
values were the same. Something like lamp.type = Mesh.Modes.Twosided,
for example. If we use strings instead of ints this can be prevented easily.
--
Willian
More information about the Bf-python
mailing list