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

[Toni Alatalo]

Campbell Barton kirjoitti:
> Here is my rationale for making these decisions,

thanks for explaining, a quick reply to explain my POV:

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

but it is not exactly similar to those. in those examples you have are 
using a separate constructor (there the list literal, ''). to add a diff 
type you'd do set.add(Thing()) .. not thingset.new().

> having bpy.Group() and bpy.groups seems to over complicate things

then again, Group is already there .. 
http://members.optusnet.com.au/cjbarton/BPY_API/Group.Group-class.html 
.. it just misses a constructor.

> * 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..

i guess this hints what the difference in our thinking is: i want bpy to 
be as normal Py as possible, while still making sense within the Blender 
architecture. this might be different from what a Blender user with no 
other Py experience expects. but still i would not differ from other py 
lightly: even people who write simple scripts may have used Py elsewhere 
too, like for web pages or games. and usually there always is a constructor

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

no, it is not about adding a mesh to scene, it is creating a new Mesh 
while working on a scene :)

this is the style at least Soya3d uses. i dont remember how it is in 
Ogre or CS.

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

i agree that duplicating is bad. my main argument for Sound() in favour 
of sounds.load() is the same than for the whole note, that it would be 
similar to other tools .. like in pygame you open an image by saying 
myimg = pygame.Image(pathtofile) .. and i don't know anything else where 
you'd do images.load, nor any other place where iterators/sequences to a 
type would be used instead of the type/class for anything else either. 
it is neat but different. and i certainly agree that having the 
iterators is great and the whole bpy model what we need (instead of the 
flawed modules-model in the old Blender), just wanted to raise this 
consideration swhile we still can debate. guess i made my point clear 
now, will sit back quietly and listen what others think for a while now.

again one argument for images.new / .load() againts Image() is that like 
you said, unlike e.g. the pygame.Image() constructor, in Blender it is 
automatically added to the project - not only instanciated in memory. if 
you save the project after loading, it will be automatically be a part 
of it. in that sense Blender works like a database, or well an 
application, you work with it by using the tools it has to create data - 
you dont create data on your own, like with a library like Pygame or 
PIL. perhaps with this rationale i can make myself accept this different 
model, am not sure yet..

~Toni
> 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
>>
>
>