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

[Dalai Felinto]

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
>