[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