[Bf-committers] BGE API Proposal

[Campbell Barton]

Toni, reply to some of your points


* A new module wont change much unless you also change the types that
module returns for GameObjects, Scenes, Cameras etc. The BGE api makes
something like NMesh to Mesh impossible because the C++ classes
themselves have the PyObjects built into them.

* Having method arguments per functions is verbose and wont work for attributes.

* Having a single setting that can be controlled by the script on and
off makes more sense to me because it can be accessed from 1 place and
the api can add checks wherever it needs to.

-- 
- Campbell



On Thu, Feb 19, 2009 at 10:41 PM, Toni Alatalo <antont at kyperjokki.fi> wrote:
> On Feb 20, 2009, at 5:00 AM, Campbell Barton wrote:
>
>> Im not satisfied with a new Module name for API changes - (will be a
>> mess in the API C++ code)
>
> i thought it would be the least mess there, 'cause there would be
> simple a copy of the old one lying around for legacy things (books, old
> files) to work, and no mixing of old and new behaviour in the same c++
> files,
>
>> GameLogic.compatibility = "2.4" # to enable the prefix
>
> .. which you'd get with this solution, similar to the other proposal of
> passing vernum in args (basically ifs in the api code).
>
> but,
>
>> Or arguments for API version numbers is overkill if you only want to
>> change small things like how getting the name works.
>
> i do agree that it may be overkill for such small changes. is not about
> a new API, just sanifying the existing a bit.
>
> but thought it would be a clean and simple way to provide full bw
> compat as that seemed to be important for some here.
>
>> NMesh -> Mesh was not that hard to update scripts for.
>
> also a nice example where having the new behaviour in a new module was
> clean and clear (but of course also the only option as it was a full
> rewrite from scratch with all different functionality, thin wrapping
> instead of thick).
>
>> Im still not convinced that a few simple breaks the API is as bad as
>> some would make out,
>> Its a hard argument to make because Breaking the API is bad right?
>
> indeed. simple stupid things you are tempted just to make nicer in
> place, but it is a valid concern that bw compat should not be broken in
> vain. when using the BGE api long ago i was also annoyed by those
> quirks so am in favor of the revamp. my old stuff mostly only works on
> old versions anyway so i use them (even back to 2.25 sometimes :) for
> running it, and also would be happy to port for new versions, so have
> no issue really - just mentioned a possibility for those for whom bw
> compat seemed to be more important.
>
>> - Campbell
>
> ~Toni
>
>> On Thu, Feb 19, 2009 at 12:25 PM, Toni Alatalo <antont at kyperjokki.fi>
>> wrote:
>>> On Feb 19, 2009, at 12:37 PM, Roger Wickes wrote:
>>>
>>>> APIVER=248
>>>>  myob=camera.New(type='persp', name='CamData', apiver=APIVER)
>>>
>>> I think a better way to do this is to have the different versions of
>>> the API as a different module.
>>>
>>> The current BGE module is 'GameLogic' (or however the capitalization
>>> is) - perhaps the new could be .. 'game' or 'bge' or 'blendergame' or
>>> something?
>>>
>>> So old scripts could continue working as they are, per Erwin's request
>>> - use 'import GameLogic' and get obnames complete with the 'OB' prefix
>>> etc.
>>>
>>> New / ported scripts would do 'import BlenderGame' or something and
>>> get
>>> ob references, have .name without 'OB' prefixes etc. and all the other
>>> sane things.
>>>
>>> Would be clean - the old api would be just what it is, no mixing of
>>> such diffent behaviours for different versions etc - could be kept
>>> around for possible 2.49 at least as it is (possibly with bugfixes
>>> applied to there too).
>>>
>>> ~Toni
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>