constructors (Re: [Bf-python] More Proposed API changes.)
cbarton at metavr.com
Mon Mar 12 16:23:12 CET 2007
Joe Eagar wrote:
> Toni Alatalo wrote:
>> >>* 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
> The problem with constructors, is they imply independent types. Nothing
> in bpy is "independant", nearly everything is part of linked lists. A
> constructor of a type should create an independant, garbage-collectable
> instance of that type. It shouldn't do other things, like automatically
> add the instance to
> a linked list. This is why the iterator.new() stuff is better, it tells
> the user what's really going on.
> So if a user does, "mesh = bpy.Mesh()", is he going to realize that mesh
> is automatically added to bpy.meshes? What will he think, when he
> realizes it isn't garbaged collected?
> Anyway, just my 2 cents.
This is my main point...
however we could make it that python types dont add to the linked list
I dont see much use in this tho, it would probably end up in users
making new data, and
A) getting errors when applying the data (because its not linked)
B) The data could get automatically linked into Blenders listbase, which
would make it hard for scripters to keep track of what was in or out for
If it was manual, then there is only 1 place the data can ever go.. (a
scene can only ever be in G.scenes) - removing it and having it only as
a python object could open a can of worms with user counts.... or trying
to link objects to a scene that wasnt in G.scenes would be tricky too...
maybe one day blender can have 2+ blends open at once, but for now, data
outside a linked list is problematic.
overall, I think its a solution looking for a problem.
Were better off accepting blender's data dosnt map into a pythonic API
as well as it might.
More information about the Bf-python