[Bf-committers] Removing auto registration

[Martin Poirier]

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