> It should be even more trivial with automatic registration. And yet in reality...
Here's the thing: I'm speaking as someone who was not involved in designing the system. For someone who doesn't have knowledge of the internals of how auto-registration works, it becomes a magical system with semi-unpredictable and unclear rules. Like, what gets registered? What doesn't? How do I control that so that I can structure my code how I want to? When do things get registered? Etc. And to make things concrete: it is not obvious, for example, how I should structure my code so that I don't get weird errors like this upon enabling an addon a second time: http://www.pasteall.org/16500 (Hint: after randomly trying things with no particular logic, I discovered that if I move my ID property class definitions into the register function, some--not all--of these errors go away. But why that is? No idea. It's not intuitive at all, and therefore a crap-shoot to solve. And it's also patently silly that I have to move those class definitions there at all.) > It removes a lot of needless boiler plate code It removes a _trivial_ amount of boiler plate code. One register/unregister call per class is not a lot of code. > as well as the possibility of easier debugging in those cases where > registration fails and gives a easy way internally to figure out what > is defined where. It is still quite easy to find classes with registration problems, because they are referenced by name in the explicit registration calls. If one of my panel classes fails to register, it is not going to be at all difficult to track down. Unless I'm misunderstanding what you mean? > it ensures that every script is a "good citizen" and correctly > registers and unregisters RNA types when the system needs > and not when bad code mistakingly does it Sure, I can see garbage collection parallels, for example. And I agree that this is nice. But what I dislike about it is that it forces the scripter to structure their code in specific ways (a subset of what python allows, see your mixin comment for example) that may not be most appropriate to the problem at hand, or to their preferences. _And_ more importantly it introduces a new set of (non-obvious) rules that the scripter has to be aware of beyond just python itself and the blender python API. It really does feel like additional language restrictions. On top of mystical magic. > The rule is that only valid well defined classes should derive from RNA > types, so if you have common behaviors to define, use mixin classes. But this is a silly and needless restriction. At the _very least_, if we stick with auto-registration we ought to do something like using decorators to specify what gets registered. Something like: @bpy.register class MyPanel(bpy.types.Panel): blah blah blah At least that way the scripter explicitly knows what is going to get registered, and can control that. It would also remove some of the confusing "magical" feeling of the whole thing, and would allow people to structure their code as desired/needed. --Nathan On Thu, Oct 28, 2010 at 8:25 AM, Martin Poirier <the...@yahoo.com> wrote: > Hi Nathan, > > --- On Thu, 10/28/10, Nathan Vegdahl <ces...@cessen.com> wrote: > >> I think this may be one of those things that is convenient >> in simple >> cases, but is just troublesome in complex cases. For >> example, I'm >> still struggling to figure out how to make the Rigify addon >> unregister >> cleanly. Ditto with the porting project I did. >> It doesn't seem >> possible. But it was trivial with manual >> registration. > > It should be even more trivial with automatic registration. The only thing > you need to take care of is registered properties, and I'm not even sure if > those can be deleted correctly at this point (Campbell could confirm this). > > Registered properties is still the biggest pitfall, IMHO, and needs to be > addressed. (that doesn't have much to do with automatic registration of RNA > types though) > >> I would much rather manage the registration and >> un-registration >> manually, so I can guarantee that everything works cleanly >> even in weird corner-cases. > > Can you give an example of such a corner case? > > Or better yet, when you encounter a problem, please mention it on this list > (or to me directly, if you don't want to do it on a public channel) and it > will be looked it. The code is certainly not perfect and there's a couple of > things to keep in mind when coding that was much free for all before (I see > that as a good thing). > >> And it makes it difficult (impossible?), for example, to >> write a class >> (say, a panel) that is just meant to be inherited from, but >> not >> directly registered. > > There's some examples of that in the UI scripts (properties_material.py look > for the MaterialButtonsPanel class and its subclasses). The rule is that only > valid well defined classes should derive from RNA types, so if you have > common behaviors to define, use mixin classes. > > I actually think it's cleaner this way. When reading code, it's easier to see > which classes define behaviors and which are actual RNA types. > >> Anyway, just my 2 cents. I'm finding >> auto-registration to be a >> needless headache, for only minor convenience gains in >> simple cases. > > I'm finding the same thing, except in reverse. > > It removes a lot of needless boiler plate code, it ensures that every script > is a "good citizen" and correctly registers and unregisters RNA types when > the system needs and not when bad code mistakingly does it, it transparently > enables optional add-ons as well as interactive execution in a text buffer, > it gives a single point of entry for registration calls as well as the > possibility of easier debugging in those cases where registration fails and > gives a easy way internally to figure out what is defined where. > > Martin > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers