[openstack-dev] [Solum] Some initial code copying for db/migration
m at metacloud.com
Tue Nov 19 01:04:11 UTC 2013
On Mon, Nov 18, 2013 at 1:58 PM, Christopher Armstrong
<chris.armstrong at rackspace.com> wrote:
> On Mon, Nov 18, 2013 at 3:00 PM, Dan Smith <dms at danplanet.com> wrote:
>> Sorry for the delay in responding to this...
>> > * Moved the _obj_classes registry magic out of ObjectMetaClass and
>> > into
>> > its own method for easier use. Since this is a subclass based
>> > implementation,
>> > having a separate method feels more appropriate for a
>> > factory/registry
>> > pattern.
>> This is actually how I had it in my initial design because I like
>> explicit registration. We went off on this MetaClass tangent, which buys
>> us certain things, but which also makes certain things quite difficult.
>> Pros for metaclass approach:
>> - Avoids having to decorate things (meh)
>> - Automatic to the point of not being able to create an object type
>> without registering it even if you wanted to
>> Cons for metaclass approach:
>> - Maybe a bit too magical
>> - Can make testing hard (see where we save/restore the registry
>> between each test)
>> - I think it might make subclass implementations harder
>> - Definitely more complicated to understand
>> Chris much preferred the metaclass approach, so I'm including him here.
>> He had some reasoning that won out in the original discussion, although
>> I don't really remember what that was.
> It's almost always possible to go without metaclasses without losing much
> relevant brevity, and improving clarity. I strongly recommend against their
I think this is simple and to the point. ++ Metaclasses have their
places, but it really makes it hard to clearly view what is going on
in a straight forward manner. I would prefer to keep metaclass use
limited (wherever possible) with the exception of abstract base
classes (which are straightforward enough to understand). I think the
plus of "avoiding decorating things" isn't really a huge win, and
actually i think takes clarity away.
More information about the OpenStack-dev