[Bf-python] Naming conventions - part I

[Michel Selten]

On Fri, 2003-06-20 at 12:40, Willian Padovani Germano wrote:
> 2) We've used the prefix M_ for the module functions and C_ for our new
> Blender Types type and methods.  I used that back when I started to make
> a clear distinction between module and type implementations in a single
> file.  M_ for module, obviously, and C_ for python "C"lass.  This is not
> good, it looks like some lib naming convention, like SDL_, etc. Class
> isn't even a C concept.
> 
> What about BPy: BPyCamera, BPyObject, etc.?  For readability, of course,
> we use BPy_Camera, BPy_Object.
> 
> ** Substitute C_ for BPy_ , ok?

After thinking about it a little more, this sounds like a good idea!

> For the M_ one, I have no good suggestion.  Bpython used CameraModule
> instead of M_Camera.  BPyM_ or BPyMod_ looks (to me) polluted, not
> immediately distinguishable from BPy_ (though BPY_ is not that different
> either, but still acceptable).  Leave it as M_ ?

I can't think of a good alternative either. So leave it for now. Unless
of course somebody comes up with a good alternative!

> 3) In a module file we have:
> 
> Module functions: M_Object_Get()
> PyType methods - specific:   Object_getData()
> PyType methods - default:    ObjectDealloc
> public functions: M_ObjectCreatePyObject(), M_Object_Init()
> 
> For readability and to keep them different from each other kind, I
> propose:
> 
> - M_Object_Get() (or whatever we use instead of M_)
> 
> - Object_getData() - no change
> 
> - Object_dealloc() - so these stay connected to the PyMethods right
> above and not the public C functions below:
> 
> - Object_CreatePyObject(), Object_Init() -- because M_ would be only for
> Python module functions like M_Object_Get().
> 
> It's better to have a convention and clearly separate these 4 groups
> that occur inside each module file.  No need to follow the one I put
> above, it's open for discussion.

Good ideas here Willian! I see no problem in applying (and updating) the
source files for exppython with this.

With regards,
	Michel