[Bf-committers] Removing auto registration

[Ton Roosendaal]

Hi Martin,

Not capable of grasping your discussions with Campbell on this topic,  
I proposed to ask arbitration by a third person who knows this well.  
We're all equally stubborn fallible humans you know, and who's "right"  
or "wrong" then is less relevant than just moving forward. :)

If you think Brecht has all information you want him to know, let's go  
for his advice.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 17 Jan, 2011, at 14:20, Martin Poirier wrote:

>
>
> --- On Mon, 1/17/11, Campbell Barton <ideasman42 at gmail.com> wrote:
>
>> Agree panel order shouldn't be a
>> factor in this discussion, it should
>> be solved irrespective of registration so addons panels can
>> be added in a logical order.
>
> Ideally, this should be done before going out of beta.
>
>> Though I'm still for auto-registration removal even if its
>> bug free,
>> most likely re-iterating from previous mails.
>
> It's not so much the reiteration of your same arguments that bugs me  
> but the fact that you've completely ignored the problems with the  
> registration order and properties registration that I've highlighted  
> many times and that has to be dealt with regardless of the  
> registration method if we want to correctly and cleanly handle  
> enabling and disabling addons (which you seem to think is an  
> argument for manual registration but is completely irrelevant).
>
>> - to me it feels mysterious that blender is operating on
>> classes
>> without being asked & errors don't trace back to
>> authors code.
>
> The traceback issue can be fixed quite simply. The Metaclass has  
> more info than manual registration on the class definition itself  
> (you can have the file and line where the class is defined if that's  
> what you want).
>
> As for blender operating on classes without being asked, that's the  
> whole point of inheritance.
>
>> - in simple cases where all classes are registered its not
>> a big win
>> to have it automatic, in complicated cases of dynamic
>> runtime registration this gets in the way.
>
> Yes, you did raise that point last time, it was bunk back then too.
>
> Can you show an example of dynamic runtime registration that deals  
> correctly with registration order and unregistration without making  
> a truckload of assumptions or not working at all?
>
> Registration order is tightly coupled with internal workings of  
> Blender, exposing that to python is completely ridiculous.
>
>> - it makes internals more complicated we need to support -
>> 3 cases:
>> direct execution, modules and addons.
>
> There's only two cases, runtime execution and delayed execution.
>
> Modules are addons that are registered automatically after definition.
>
>> - Matt Ebb and Nathan Vegdahl have complained about
>> auto-registration
>> in its current state fir renderman support which does
>> dynamic
>> generated classes from shaders, and rigify for rig types.
>
> Didn't I addressed Nathan's issues last time?
>
> There's nothing about autoregistration that prevents runtime  
> definition of classes.
>
>> It is regrettable that I accepted this patch in the first
>> place, but I
>> felt some obligation to do so since Martin addressed the
>> issues that
>> concerned me, also because Brecht and Andria also approved
>> of this
>> functionality at the time.
>
> It's regrettable that I tried to address the real problems two  
> months ago, after which you said you'd have to look into it yourself  
> and never came back until now, trying to force a decision again.
>
> It's regrettable that you think autoregistration is an opaque black  
> box just because there's the word metaclass in there.
>
> But most of all, it's regrettable that you think shoving that back  
> in the ands of python developers will solve all problems magically  
> when in fact it means having to write more documentation with  
> warnings all over the place about proper registration order.
>
> Martin
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers