This is a pretty cool implementation. Another option if you are supporting
python 2.6 or greater would be to use class decorators. They may make it
more apparent that something special is happening with that class rather
than having to know the details of metaclasses.
class Factory(object):
@classmethod
def register_handler(cls, handler_cls):
if not hasattr(cls, 'registry'):
cls.registry = dict()
key = getattr(cls, 'key', handler_cls.__name__.lower())
cls.registry[key] = handler_cls
@Factory.register_handlerclass Letter(object):
def execute(self, receiver, envelope):
pass
Just another option :).
On Mon, Jun 2, 2014 at 10:38 AM, Marcus Ottosson <[email protected]>
wrote:
> Dynamic Registration versus if/else
>
> A few posts back, we spoke about how to simplify long (50+) if/else
> clauses. We had two approaches:
>
> *if/else*
>
> if something == this:
> then do thatelif something == this_here:
> then do this other thing
>
> *hashmap*
>
> As suggested by Justin (hope I understood you correctly)
>
> map = {
> 'this': then do that,
> 'this_here': then do this other thing
> }
>
> map[something]()
>
> *dynamic registration*
>
> I tested a third alternative, involving metaclasses. I’m generally not a
> fan of metaclasses and tend to stay clear, but in this case the gain may
> outweight the hassle.
>
> 1.
>
> Use
>
> <https://github.com/abstractfactory/labs/blob/523b0255d637e2c8e861d60d22ce55790918cb01/python/messaging/chat/swarm.py#L103>
> 2.
>
> Baseclass
>
> <https://github.com/abstractfactory/labs/blob/523b0255d637e2c8e861d60d22ce55790918cb01/python/messaging/chat/lib.py#L8>
> 3. Implementation
>
> <https://github.com/abstractfactory/labs/blob/523b0255d637e2c8e861d60d22ce55790918cb01/python/messaging/chat/mediator/swarm.py>
>
> In a nutshell, each handler is a subclass of Factory which, upon
> subclassing, registers said subclass and provides an interface for it. At
> this point, there is no additional if/else statement, no hashmap to update,
> just subclass the Factory, and it’s handled. Including logging, error
> handling and anything surrounding it. Basically resulting in leaner code,
> at the expense of being more difficult to understand (you’ll need to
> understand metaclasses, for starters)
>
> Let me know what you think.
>
>
>
> On 2 June 2014 15:26, Marcus Ottosson <[email protected]> wrote:
>
>> Cool, thanks Tony. I think it’s perfectly fine to have your own
>> definitions, but for the sake of this conversation, it would be really
>> helpful if we can all referred to the same thing.
>>
>> Sounds like we’ve got two definitions going on, let’s find a more
>> appropriate wording for them:
>>
>> 1. Signature defined prior to sending a message across the wire,
>> pre-validated
>> 2. Signature defined after being sent, post-validated.
>>
>> *pre-validated*
>>
>> Where the signature must match the Python stdlib “json” module
>>
>> >>> proxy.json.dumps({"c": 0, "b": 0, "a": 0}, sort_keys=True)
>>
>> *post-validated*
>>
>> Where signature may differ, so as to be fit for multiple languages even
>> those without the ability to sort the keys. The receiver decides what to
>> use.
>>
>> >>> proxy.send(
>> {'address': 'json',
>> 'payload': {"c": 0, "b": 0, "a": 0},
>> 'sortKeys': True}
>> )
>>
>> It’s an amazingly interesting topic, as it relates to where to put the
>> responsibility; on the user, or the recipient.
>>
>> Do the examples make sense, is this what we’re referring to?
>>
>>
>>
>> On 2 June 2014 14:43, Tony Barbieri <[email protected]> wrote:
>>
>>> It enables a system to make calls to programs such as NFS across the
>>>> network transparently, enabling each system to interpret the calls as if
>>>> they were local. - Definition of RPC
>>>> <https://www.google.co.uk/webhp?sourceid=chrome-instant&rlz=1C1CHFX_en-GBGB568GB568&ion=1&espv=2&ie=UTF-8#q=define%20rpc>
>>>
>>>
>>> Not to continue the debate but I am using messaging to perform tasks
>>> much like that definition ;). For example, when a worker picks up a task
>>> it will execute the code on the machine the worker is running on which may
>>> end up invoking the procedure call remotely if the worker is running on a
>>> remote machine.
>>>
>>> I think the biggest difference between RPC and messaging is what Justin
>>> outlined above:
>>>
>>> But to me, the RPC aspect is that it presents a predefined interface. A
>>>> function with a signature. This signature is validated as part of the RPC
>>>> implementation before it goes onto the wire.
>>>
>>>
>>> With messaging, no validation happens in regards to the message
>>> contents. The message is sent off to the broker and if there is a
>>> worker/consumer present that can deal with that message it does so. If
>>> there is not a consumer present that knows how to deal with the message
>>> then nothing happens unless either a timeout occurs or a consumer comes
>>> online that can deal with it. With RPC you have an explicit contract and
>>> at the time of invoking the RPC call, the call signature will be validated
>>> either client side or server side. If a contract was never created for the
>>> call signature an exception will be raised right then.
>>>
>>> This is that what I consider the major differences between RPC and
>>> messaging are...
>>>
>>>
>>>
>>> On Mon, Jun 2, 2014 at 2:10 AM, Marcus Ottosson <[email protected]>
>>> wrote:
>>>
>>>> I feel it is an implementation detail and not the sole definition of RPC
>>>>
>>>> I think this is where we went off the rails.
>>>>
>>>> It enables a system to make calls to programs such as NFS across the
>>>> network transparently, enabling each system to interpret the calls as if
>>>> they were local. - Definition of RPC
>>>> <https://www.google.co.uk/webhp?sourceid=chrome-instant&rlz=1C1CHFX_en-GBGB568GB568&ion=1&espv=2&ie=UTF-8#q=define%20rpc>
>>>>
>>>> From now on, let’s refer to RPC as being this, ok? :)
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Python Programming for Autodesk Maya" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCs7mvdqVbcwBgsbfBR-G_k72kny1hvCubD%2BOXtTwNkRw%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCs7mvdqVbcwBgsbfBR-G_k72kny1hvCubD%2BOXtTwNkRw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> -tony
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Python Programming for Autodesk Maya" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsQbE2gZvod9fiq0_ea2ggx4NobhtMVOiYkr2qcBiGXxoQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsQbE2gZvod9fiq0_ea2ggx4NobhtMVOiYkr2qcBiGXxoQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> *Marcus Ottosson*
>> [email protected]
>>
>
>
>
> --
> *Marcus Ottosson*
> [email protected]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBCN6JYo6jhxFrVJe0XvTjUQzG0hxbpK96X3WOZJcTJCw%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBCN6JYo6jhxFrVJe0XvTjUQzG0hxbpK96X3WOZJcTJCw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
-tony
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsQbe%2BJiamvwpjV9UEhXHDqXUmYB%2BFf22DzGyfi2XPg76g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
