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

[Joseph Gilbert]

Campbell Barton wrote:
> lets them add objects without realizing that the object is being added 
> to a scene's objects, or that a scene stores an object at all.
Again like Toni said, if the object constructor takes a 'scene' argument 
which defaults to the active scene then you don't have any trouble.
> Id rather force them to add an object through the scene...
Having this heirarchy where you call .new() on the last branch is, imho, 
more effort than calling the class constructor with the parent as an 
argument.
Why not:
o = Object(bpy.scenes.active)
instead of
bpy.scenes.active.objects.new() ?

Forcing the script writer to iterate a tree of iterators doesn't appear 
to be more simple/friendly on the surface.

Campbell Barton wrote:
> at this point I think its waisting more time in discussion then it 
> should, can we call on the/a benevolent dictator(s)?
>
> As for the bpy.Mesh() vs bpy.meshes.new(), I thaught we decieded go go 
> with the latter a while ago..
The benevolent dictator has already spoken. IIRC it went something like 
"class constructors are part of some imaginary api". However, in the 
world of post-'we' decision making it's nice to be able to discuss it on 
the ML, even if it doesn't change how it's implemented in any way.

 From a practical standpoint we don't have class constructors in the api 
(other than Armature() which was supposed to be a test case), so I can 
see that this may require work that we just don't want to do at this 
point. .new() is in keeping with the current api. I do think however, 
the discussion is relevant as the addition of these methods, in the 
future, to type classes would make them callable from outside a module, 
and the issue of how to instantiate classes would rise again.

Toni Alatalo wrote:
> my thinking tends to escape to a future where there is no Object, 
> except as an abstract basetype, that MeshObject, ArmatureObject etc. 
> implement. this being in-line with Ton's argument that the api should 
> be 'object level'.
Already been discussed, but I think that this type of shift would be 
interesting and worth a further discussion later on.

Joe Eagar wrote:
> The problem with constructors is they imply the created object is 
> fully under the control of the script author, when really it is not.  
> For example, you can create a mesh, but if you want to delete it 
> you'll have to save-reload the file.  Or you have a piece of wrapped 
> data, like perhaps an object, attached to a Registry dict, and a user 
> undos then redos; you might get corrupt data.
If a script writer doesn't understand that Object() creates data in a 
scene and objects.new() does, than he can always consult the documentation.