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

[Michael Reimpell]

> i dont think the bpy instance attributes should be limited to the c struct 
> elements. instead of bone.setTransformation(matrix), why would we not have a 
> modifiable bone.matrix? it is still a thin wrapper (manipulating bpy bone 
> matrix actually modifies the internal rotation things), just via a different 
> interface (which is friendlier to e.g. importers).
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 any 
other (unwanted) side effects as well. This is a good example of bad design: 
unpredictable side effects. In contrast, everyone would expect 
bone.setTransformation(matrix) to update the necessary data. Having derived 
data as attributes leads to confusion as attributes are no longer immediate 
attributes.

> the reason why in some other languages, like Java (and C++ i suppose), there 
> are so-called 'setter' and 'getter' methods is that if some attribute 
> requires some special code, like getting the value of it from a database or 
> calculating it based on some other internal attributes, it has to be called 
> as a method for it to be able to include the code to do that. Python does 
not 
> anymore have that limitation so all necessary values can be exposed 
normally.
You could do direct assignment of attributes via operator overloading in C++ 
as well. The reason for getters and setters is "hiding the implementation". A 
concept that has proven to be very successful.

Cheers,
Michael