methods vs. properties, and tests and code reference (Re: [Bf-python] API overhaul - irc meeting?)

[Toni Alatalo]

On Sunday 08 January 2006 18:12, Michael Reimpell wrote:
> > struct elements. instead of bone.setTransformation(matrix), why would we
> > not have a modifiable bone.matrix? it is still a thin wrapper
> Because assigning a matrix to that attribute would have the strange side
> effect, that other attributes get changed too. If there is a bone.matrix
> you have to lookup in the API docs, if you are supposed to change the head,
> tail, roll values as well, or if it does so automatically, and if there are

good point, but after some consideration, i think not at the end a strong 
counterargument. for example, the popular sdl-wrapper + niceties Pygame 
library has a rectangle class called Rect, which has what the doc seems to 
call 'virtual attributes' such as 'center' and 'bottomright', which are 
assignable, so you can do rect.center = (50,50) or rect.bottomright = 
(200,80). see http://www.pygame.org/docs/ref/rect.html

they were made before Python had properties, just by using the set_attr 
mechanism (except on the c level i think), have been there for at least 5 
years i think.

> any other (unwanted) side effects as well. This is a good example of bad
> design: unpredictable side effects. In contrast, everyone would expect

obviously modifying one modifies the other as a side-effect too, but the 
side-effect is not unwanted nor unpredictable: quite the opposite, it is 
expected and wanted, as the different attributes/properties exist exactly for 
the purpose of having several different ways to modify the same internal 
aspects of the object - different ways suiting different purposes.

> bone.setTransformation(matrix) to update the necessary data. Having derived
> data as attributes leads to confusion as attributes are no longer immediate
> attributes.

for someone who does not understand what matrices and rolls are, 
setTransformation() does not make it really clearer that it modifies 
bone.roll etc. in any case it is a relation that the programmer must either 
know from understanding how 3d systems work, or from reading the 
documentation. if you/we think 'transformation' is a better word, the 
property can be called that too, so you can do bone.transformation = matrix

during the years i have been on the pygame-users list and used that library in 
several projects, i have never heard about nor experienced problems with 
those side-effecting / alternative ways of moving rectangles, so i dont think 
similar design would be bad in Blender either -- instead i believe it is such 
nicety that users of python libraries have come to expect. am still trying to 
be open for being proven wrong, but i dont think that has happened yet.

another example i either recall or imagine is for moving objects in games, 
which can have both ob.vector for the motion vector, and ob.speed - obviously 
also there modifiying either modifies both (speed being just a convenient way 
to access len(vector) (or is it vector.len))

> Michael

~Toni