[Bf-python] Final Ipo/IpoCurve API revisit

[Gilbert, Joseph T.]

We should stop using strings as parameters imho to stick with the future
api consistency rules. In the past we coded a lot of
function('string_parameter') type functions which looks ugly. If we can
use constants all the better.

Yes it means a lot of constants but even if you use strings they have to
be documented somewhere, and the user will have to wade through 160
constants in an updated bpy api manual somewhere. 

""" per-Ipo attribute which provides a dict or list of just the 
constants for that Ipo type"""
I like this idea but with constants. Remember that if your returning
constants loaded into the module dictionary and return some subset of
this to the user you're simply passing him a reference to objects that
already exist in the module's dictionary rather than creating a ton a
strings to return to the user.

The above would seem to solve some of the difficulties with the shape
ipos is my guess but I don't really know :).  Is there any reason that
shape ipos with no name, identifier be given one for the purposes of
script identification?

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Ken Hughes
Sent: Thursday, April 13, 2006 12:26 PM
To: Blender Foundation Python list
Subject: [Bf-python] Final Ipo/IpoCurve API revisit

OK, this is the last step prior to my Ipo update:  it's actually a 
two-part question.

antont, stivs and I discussed on IRC two weeks ago whether Ipo curves 
should be accessed by a string ("ipo['LocX']") or a constant 
("ipo[LOCX]").  The disadvantage of strings is... well, they're strings,

while the disadvantage of constants here is where to get them from.  As 
I see it, we would have to declare constants in the Ipo module for every

possible Ipocurve type (which as I count them is at least 160 constants)

or have a per-Ipo attribute which provides a dict or list of just the 
constants for that Ipo type.  I already have something like this for the

string implementation.

The real sticking point of using constants are Key/Shapo Ipos:  they do 
not have a specific name or number, and can be renamed by the user, so a

constant would not work naturally for them.  Shape Ipos can be accessed 
through the Key API, however, and are currently broken in the Ipo API of

2.41, so one solution would be to remove access for them thru the Ipo 
API completely.  However, using strings to access the Key Ipocurves 
would be simple to implement.

My plan, unless people think otherwise, will be to stick with the 
current string implementation.  At worst, people will not like it and 
I'll reimplement portions of the code using constants instead before the

next release.  But if you have an opinion, please speak up soon.  I plan

to commit to CVS sometime next week.

Ken

_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python