constructors (Re: [Bf-python] More Proposed API changes.)

[Campbell Barton]

Hi Antont,
thanks for your input, even if I disagree, it keeps me on my toes and I 
may be on the wrong track with the direction of the API.

Here is my rationale for making these decisions,

bpy.groups is an iterator that gives access to all groups,
bpy.groups.new('someGroup') is adding a new element to that pool of 
data, similar to
  - set.add('')
  - list.append('')

having bpy.Group() and bpy.groups seems to over complicate things
* A new or casual user has to remember that a slightly different word is 
used to make the data and another is used to loop on it..

* ob = bpy.Mesh(scn, me) - is adding the mesh to scn, seems less logical.

* What we currently have is consistent with other areas of the API, 
(maybe only areas I work on? not sure)
   metaball.elements.add()
   group.objects.link()
   ob.modifiers.add()

If this is a bad direction for the API then we can move in a new 
direction but then we end up with an inconsistent API all over again... 
realisticly I think its getting too close to 2.44 for that.

Also, using an existing type with .new() or .load() is explicit in what 
its doing..

 >>> ob = bpy.Mesh(scn, me)
adds a new variable but dosnt actually say what its doing. Theres little 
difference about Mesh and meshes, that indicates one is for making a new 
data and another is to loop on and another it to create new data.

I have to disagree about having multiple syntax. bpy.sounds.load(...) 
and bpy.Sound(...)

The advantage of this new API is that it has significantly less 
duplicate code then the old one, which means easier to maintain. adding 
bpy.Sound(...) dosnt give any real advantage.

We are going to maintain the old API but the last think I wasnt is to 
have C and EPY Docs and code for 3 ways to create a new mesh... We'll 
end up spreading ourselves too thin, and none will be well documented, 
even having to make each method, crosslink to the other method would be 
a pain...



Toni Alatalo wrote:
> Campbell Barton kirjoitti:
> 
> letting this sink more, this feels like the greatest thing for bpy :)
> 
> but another thing.. i dont want to start a huge endless debate, like we 
> have had many on irc around these things, but i still want to voice this 
> out:
>> http://members.optusnet.com.au/cjbarton/BPY_API/Bpy-module.html
> 
> i'd prefer constructors over dataiterator.new s.
> 
> the problem that scene members can not live alone could be nicely 
> overcome by requiring a scene instance as an argument for the 
> constructor. so instead of:
> 
> scn = bpy.scenes.active
> me = bpy.meshes['mymesh']
> ob = scn.objects.new(me)
> 
> i'd like:
> 
> scn = bpy.scenes.active
> me = bpy.meshes['mymesh']
> ob = bpy.Mesh(scn, me)
> 
> 
> creating by passing the context to a constructor is for me the 
> equivalent of having a scene open in the UI and creating.
> 
> especially because not all things even are in a scene like that!
> this is awkward:
> 
> snd = bpy.sounds.load(sound_dir + filename)
> 
> why would you create something via the iterator for those things?
> this i think would be better:
> snd = bpy.Sound(sound_dir + filename)
> 
> the fact that that snd is then also in bpy.sounds is ok, i think a good 
> side effect - but the iterator is not what you are concerned about when 
> creating, just the type! these are of course not mutually exclusive, if 
> you want to keep .new and .load too, but i hope you seriously consider 
> having constructors (too).
> 
> ~Toni
> 
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
> 


-- 
See MetaVR Visuals Used at the Combat Studies Institute
http://www.metavr.com/casestudies/baghdadviews.html

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