[Bf-committers] BGE API Proposal
Roger Wickes
rogerwickes at yahoo.com
Thu Feb 19 11:37:02 CET 2009
I think the issue is whether or not to preserve old API calls. We could either append a version suffix to the call, or accept a version parameter, as a means of ensuring scripts don't break with every new release. For example, it is possible to append a suffix to an API call, such as
myob=camera.New_248(type='persp', name='CamData')
and then that way, if the API for camera.New changes to like, using an ordinal instead of a literal, it becomes camera.New_250(type=PERSP, name='CamData') where PERSP is a constant. I personally don't like that approach, but have seen it done.
What I do like is passing the API version as a parameter, and let the API then check and invoke the appropriate code, such as:
APIVER=248
and then
myob=camera.New(type='persp', name='CamData', apiver=APIVER)
assuming the apiver is an integer and variable parameter. I like integer as it allows easy code checking within the API itself. As a script is certified and upgraded to work with a new API, a simple line change invokes the new api calls. There is only one line to change (up front), instead of many. As older api calls get logically depricated or impossible to preserve, the code can simply if apiver<248 return ('api %s no longer supported for version %i') to the console and stop.
For scripts that use multiple API versions, something like
APIVER=250
APIOLD=248 'for new api calls I haven't gotten around to figuring out
and then
camera.New(type='persp', name='CamData', apiver=APIVER)
myob=camera.Get(name=None, apiver=APIOLD)
where, for example, the new API for Get looks like the old interface, but returns, say, a linked list or something different that the programmer either can't figure out yet, or doesn't need/want.
In summary, the frustration is that an API change breaks working code, and so scripters have to fix code that breaks with every release, a maintenance nightmare. If the API maintainer does not want or cannot maintain backward compatibility, the api just tightens up the version check and disallows anything less than the current release number.
Just a suggestion. I am not an API maintainer, but I am a pig.
________________________________
From: "blender at erwincoumans.com" <blender at erwincoumans.com>
To: bf-committers at blender.org
Sent: Thursday, February 19, 2009 1:24:47 AM
Subject: Re: [Bf-committers] BGE API - was 2.49 release proposal
Again, please don't change the functionality of existing methods, such as
'getObject', but simply use new method names for new functionality. This
avoids a lot of confusion.
Secondly, it would be good to introduce a Blender version check for BGE
python scripts (if it isn't available yet), so that script writers can
choose to be compatible with new and old Blender versions.
Thanks,
Erwin
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20090219/5ad72fc8/attachment.htm
More information about the Bf-committers
mailing list