[Bf-python] Proposed BPyAPI Additions.

[Campbell Barton]

Thanks for the feedback,
For the most part I agree with your corrections, some things I we didnt 
discuss in detail, and I made some assumtions also.

1)
scn.objects.new - My intention was to make a new object directly from 
obdata.

however others were interested in the convenience of not having to do.
scn.objects.new(Mesh.New())

# or if we change teh API as porposed somewhere else...
scn.objects.new(Mesh())

So I suggested
scn.objects.new("Mesh")
but were moving away from strings...

personaly
scn.objects.new(Mesh())
seems ok to me.and Mesh.New() until the API's altered.

Id like to avoid adding data spesific adding functions if possible.
what options might you have that are specific to a datatype?


2) scn.objects.selected - In general I like (little long but no way 
around that)
  * Could this use the same type as scn.objects but initialized with 
some different options? - making 2 pytypes for what is mostly the same 
thing is a bit annoying.
  *  In most cases people think of the selection as the VISIBLE selected 
objects, must document that it is from all layers.
  *  If scn.objects.selected is added in and works well, it may be good  
to have scn.objects.context  - Which only gets the  visible selected 
objects - (What would be moved when the user hits Gkey.)


3) DataBase name was made up, Data is fine, matches the "Data" browser., 
personally not that fussed.

On the constants side of things, Id prefer to discuss seperately, good 
points but probably outside the scope of this update.

- Cam


Martin Poirier wrote:
> Hi,
>
> Just a couple of comments on the proposed additions:
>
> I like where you're going with the iterator protocol
> implementation, however, I think some of the suggested
> uses could be made a bit better. For example:
>
> scn.objects.new(Types.Mesh): I thought we were moving
> away from those factory-like methods and into the
> realm of real object constructors? At least, get rid
> of the constant and have something like
> objects.newMesh(), then each object type method can be
> documented separated. Moreover, with the constant, you
> can't pass around object creators for specific type
> without relying on curying (wrapping it to remove the
> parameter).
>
> scn.objects.selected should be an object set (just
> like scn.objects) and you could use that to change the
> selection (with add, remove, extend, ...)
>
>
>
> For the rest, I don't quite like the DataBase name,
> that thing is far from being a database implementation
> and calling it that I think is might be a bit
> confusing. I'd propose just calling it Data.
>
> Blender.Data.objects and so on.
>
>
>
> On the Constants topic, I know that was removed from
> the proposal, but I really didn't like where it was
> going for some reasons:
> - A single constant module that is coupled with all
> the others has very bad coupling and very low usage
> cohesion. This should light a red light right away.
> - Cramming all the constant in a single module will
> quickly become overcrowded and if we're going to use
> submodules to classify them, we might as well put it
> where they belong (cohesion up, coupling down), that
> is, right in their respective classes (mesh constant
> in the Mesh class, edge constants in the edge class,
> ...).
> - Moreover, what to do if we have the same functional
> constant (does the same thing on two different object)
> with different values. (for an hypothetical example:
> if we have HardEdge on mesh = 1 and HardEdge on nurbs
> = 2).
>
>
> All in all, good ideas.
>
> Martin
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
>   


-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241