[Bf-committers] Idea: deprecate the attribute access for user properties in the BGE

[Benoit Bolsee]

My initial feeling was to keep the attribute style for the elegancy of
the syntax but after some thoughts, I come to agree with all Campbell's
points. 
I had exactly the problem he describes when converting a game of mine to
the new API that would have been avoided if attributes and properties
were separated by syntax.
Another funny problem with my VideoTexture demo was the difficulty to
explain that in the expression "GameLogic.video.source", source is a
reserved name while video is not. Using the syntax
"GameLogic['video'].source" makes it much clearer.

I propose two options: 
1) keep the attribute syntax for ever but with a "compiler" warning when
the user uses it (warning that can be turned off).
2) deprecate for 2.49 and suppress the attribute syntax for 2.50

I actually prefer the second option, for the efficiency and the
consistency of the API. A script to convert from the attribute syntax to
the dictionary syntax should be easy to use.

/benoit

>This is the reaction I was expecting from users,
>Some things to consider...
>
>* allowing properties to be accessed through attributes always allows
>conflicts if we add new attributes since SOME game may use the
>attributes as names, you could argue that we should use get/set funcs
>always however attributes have been in the BGE for a long time
>along-side get/set's too.

>* its less obvious to read, what are built in attributes and what are
>user defined ones.
>
>* typo's in setting attributes will fail silently
>
>* even though gameOb.someAttr is less typing then gameOb["someAttr"],
>I often see things like this...
>  getattr(gameOb, "someAttr" + str(i))
>  # With getitem style access it looks like this which I find less
cumbersome...
>  gameOb["someAttr" + str(i)]
>... same for setattr, hasattr
>
>* GameObject properties are a closer match to python dictionaries then
>class attributes, (they could have spaces in the name for instance).
>
>* I don't see python (or lua) coders complain that dictionary access
>is 'hard', or 'ugly'
>
>* Including both methods is OK but I prefer not to be sloppy in
>allowing multiple conventions, I never saw this before in a python API
>before and for good reason, separating the methods out also speeds up
>access (not by a huge amount but since people are writing games it
>doesn't hurt).
>
>The ONLY reason I can think to keep attribute access is that its
>slightly easier to type, but from most other reasonings Id prefer to
>drop it.