<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:tahoma,new york,times,serif;font-size:10pt">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 <br><br>myob=camera.New_248(<span class="summary-sig"><span class="summary-sig-arg">type</span>=<span class="summary-sig-default"><code class="variable-quote">'</code><code class="variable-string">persp</code><code class="variable-quote">'</code></span>,
<span class="summary-sig-arg">name</span>=<span class="summary-sig-default"><code class="variable-quote">'</code><code class="variable-string">CamData</code><code class="variable-quote">')<br><br>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.<br><br>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:<br><br></code></span></span>APIVER=248<br>
<br>
and then<br>
<br>
myob=camera.New(<span class="summary-sig"><span class="summary-sig-arg">type</span>=<span class="summary-sig-default"><code class="variable-quote">'</code><code class="variable-string">persp</code><code class="variable-quote">'</code></span>,
<span class="summary-sig-arg">name</span>=<span class="summary-sig-default"><code class="variable-quote">'</code><code class="variable-string">CamData</code><code class="variable-quote">', apiver=APIVER)<br>
<br></code></span></span><span class="summary-sig"><span class="summary-sig-default"><code class="variable-quote"></code></span></span>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. <br><br>For scripts that use multiple API versions, something like<br><br>APIVER=250<br>APIOLD=248 'for new api calls I haven't gotten around to figuring out<br><br>
and then<br><br>
camera.New(<span class="summary-sig"><span class="summary-sig-arg">type</span>=<span class="summary-sig-default"><code class="variable-quote">'</code><code class="variable-string">persp</code><code class="variable-quote">'</code></span>,
<span class="summary-sig-arg">name</span>=<span class="summary-sig-default"><code class="variable-quote">'</code><code class="variable-string">CamData</code><code class="variable-quote">', apiver=APIVER)<br>
</code></span></span><span class="summary-sig">myob=camera.Get(<span class="summary-sig-arg">name</span>=<span class="summary-sig-default">None, apiver=APIOLD</span>)</span><br><br>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. <br><br>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.<br><br>Just a suggestion. I am not an API maintainer, but I am a pig.<br><div style="font-family: tahoma,new york,times,serif; font-size: 10pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2"
face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "blender@erwincoumans.com" <blender@erwincoumans.com><br><b><span style="font-weight: bold;">To:</span></b> bf-committers@blender.org<br><b><span style="font-weight: bold;">Sent:</span></b> Thursday, February 19, 2009 1:24:47 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Bf-committers] BGE API - was 2.49 release proposal<br></font><br>
<br><br>Again, please don't change the functionality of existing methods, such as <br>'getObject', but simply use new method names for new functionality. This <br>avoids a lot of confusion. <br><br>Secondly, it would be good to introduce a Blender version check for BGE <br>python scripts (if it isn't available yet), so that script writers can <br>choose to be compatible with new and old Blender versions. <br><br>Thanks,<br>Erwin <br><br><br>_______________________________________________<br>Bf-committers mailing list<br><a ymailto="mailto:Bf-committers@blender.org" href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br><a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br></div></div></div><br>
</body></html>