[Bf-python] shared properties?

[Yann Vernier]

On Mon, Jun 23, 2003 at 03:30:47PM -0300, Willian Padovani Germano wrote:
> On Sun, 2003-06-23 at 08:09, Yann Vernier wrote:
> > I'm not sure how much of the old API has [sg]etName() functions that
> > work. If I'm not mistaken they failed to work on meshes and objects
> > (even the argument for New() was uniplemented). Could someone explain to
> > me why the method interface is necessary?
> 
> Some of them were already available in the 2.25 API and so needed to be
> kept for compatibility (though the 2.25 doc and actual code didn't
> "agree" in some points).  When I began to help, it was natural for me to
> add the missing ones, since that was the safer -- also recommended by
> the 2.25 doc -- way to access the variables (they checked the values). 
> But then I made the setattr function call the set* methods and both ways
> became safe.
> 
> We can take away most methods and only use direct access through member
> vars, leaving only the ones that were already in the API, but this is
> against a uniform interface.  And since we have the functions anyway 
> 
> -- you mention that it means two extra functions for each attr, but
> consider that setAttr would be too bloated with all the tests/cases done
> inside it (take Lamp and Material, for example) --
> 
> there's no reason not to expose them all to Python programmers.  They
> choose what they prefer to use.
> 
> Funnily the opposite of what you suggest has also been suggested: not to
> implement the get/setAttr way.  But it's better to have it because it's
> the Pythonish way of doing these things.

I'm all for keeping compatibility. The reason I needed the name
attribute in the first place was my script used it for lack of working
setName(). I thought a bit more, and it could possibly be more efficient
to use the separate methods as Python can store them in a hash. 

But can we implement the common ones as shared? It seems the blender
structs (quite intentionally) start with an ID struct. The difference is
we'd have a header file declaring these methods ([sg]etName to begin
with) and a macro to put in the method table adding the references.

-- 
PGP fingerprint = 9242 DC15 2502 FEAB E15F  84C6 D538 EC09 5380 5746
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20030624/3fb3d86e/attachment.sig>