Open Stack

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

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.

--Morgan Fainberg