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

[Campbell Barton]

+1 for deprecating later on then attributes.
Maybe deprecate at the same time we drop the 'OB' prefix since that
will break scripts too?

On Mon, May 25, 2009 at 3:23 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
> My 2 cents:
>
>> typo's in setting attributes will fail silently
> + 1
>
>> it will make writing scripts very ugly.
> + 0
>
>>its less obvious to read, what are built in attributes and what are user
> defined ones.
> +1
>
>>The ONLY reason I can think to keep attribute access is that its slightly
> easier to type
> -1
>
> Way more work to update scripts:
> -1
>
> Well we have a tie :)
> So the bottom-line for me is: If we are not going to change that again (in
> the next 3~5 years/releases) I'm ok with the change.
> However if the change is not THAT required, could we leave it as deprecated
> for longer than the set/get API?
>
> Cheers,
> Dalai
> http://blenderecia.orgfree.com
>
> 2009/5/25 Campbell Barton <ideasman42 at gmail.com>
>
>> 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.
>>
>>
>> On Mon, May 25, 2009 at 10:51 AM,  <blender at erwincoumans.com> wrote:
>> >
>> >  -1, it will make writing scripts very ugly.
>> >
>> > I rather would like to leave all options available to the user, and let
>> them
>> > choose what they prefer, including the original methods.
>> >
>> > Thanks,
>> > Erwin
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Campbell Barton writes:
>> >
>> >> +1, practically this isn't a very bug change to 2.49
>> >> it only means adding a warning since both access methods are currently
>> >> supported.
>> >>
>> >> Wasn't sure if we should deprecate attribute style access because I
>> >> taught users would complain, interesting ZanQdo and yourself asked for
>> >> this change separately, Blengine is ok about it too (as an example of
>> >> a BGE user who isn't a total python/correctness pendent :) ).
>> >>
>> >> On 5/25/09, José Ignacio <jose.cyborg at gmail.com> wrote:
>> >>> On Mon, May 25, 2009 at 1:16 PM, José Ignacio <jose.cyborg at gmail.com>
>> wrote:
>> >>>  > Proposal:
>> >>>  > Deprecate & remove attribute access for user properties in
>> >>>  > KX_GameObject in favor of the recently introduced dictionary syntax.
>> >>>  > this: obj.userprop would become: obj["userprop"]
>> >>>  >
>> >>>  > Rationale:
>> >>>  > - Dictionary access allows the used of reserved or even illegal
>> python
>> >>>  > names (like "for" and "class"), like the GUI and the logic bricks
>> let
>> >>>  > you do now (thus being consistent with them), plus preventing name
>> >>>  > clashes between these and current/future class attributes. This is
>> >>>  > very important for beginners (and maybe even people with some
>> >>>  > experience), that would start wondering "why cant i access this
>> >>>  > property in python while i can use it perfectly with logic bricks?"
>> >>>  > - It is way faster, since it doesn't have to go trough all the
>> python
>> >>>  > getattr system and dicts have very fast lookups.
>> >>>  > - Also, since names are python strings lets you do things would have
>> >>>  > to do with a __getattr() hack
>> >>>  > - Typing a class attribute wrong assignation would raise an
>> exception
>> >>>  > instead of failing silently. For example, typing
>> >>>  > # -----------------------------
>> >>>  > obj.poistion = [1, 2.5, 3] # notice the typo
>> >>>  > # -----------------------------
>> >>>  > would create a property called "poistion" instead of raising an
>> >>>  > exception, thus leading to headaches and a lot of time wasting
>> trying
>> >>>  > to find the issue. More if we are talking about beginners.
>> >>>  >
>> >>>  sorry, the last argument has some mistakes, should read as follows:
>> >>>
>> >>>  - With the attribute access removed, typing a class attribute wrong
>> >>>  in an assignation operation would raise an exception instead of
>> >>>  failing silently.
>> >>>  For example, typing in the current engine:
>> >>>  # -----------------------------
>> >>>  obj.poistion = [1, 2.5, 3] # notice the typo
>> >>>  # -----------------------------
>> >>>  would create a property called "poistion" instead of raising an
>> >>>  exception, thus leading to headaches and a lot of time wasting trying
>> >>>  to find the issue. More if we are talking about beginners.
>> >>>
>> >>>  > -- love
>> >>>  > cyborg_ar
>> >>>  >
>> >>>  _______________________________________________
>> >>>  Bf-committers mailing list
>> >>>  Bf-committers at blender.org
>> >>>  http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>
>> >>
>> >>
>> >> --
>> >> - Campbell
>> >> _______________________________________________
>> >> 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
>> >
>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> 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
>



-- 
- Campbell