[Python-ideas] Name mangling and code repetition (with cooperative inheritance use case)

[Joao S. O. Bueno]

I see -
in that case, you can have a class decorator, or even a function as a
metaclass, that creates a new _dispatch table for every subclass  - If
you are using Python 3.3 you can enven use a collections.ChainMap for
that to avoid duplicating the dictionary data once for each class.

I actually got such an example with decorators working before I read
Terry's message and thought a single - root-class based dict could
cover all use cases:

https://gist.github.com/jsbueno/6f14167b8c4631d0baa7

Using a metaclass instead of a decorator would free you from
decorating every class -
and it could just be a function receiving (name, bases, dct) as
parameters that would call "type" instead of a "real" metaclass, since
the changes can be made after the class is created by a plain call to
"type".

 js
-><-



On 8 April 2013 23:39, Zahari Petkov <zarchaoz at gmail.com> wrote:
> Right, I forgot to mention that ordering is important - this is why a
> priority sequence is needed,
> not a mapping.
>
> The case is that a subclass may need to be rendered in a different way
> than a superclass.
>
> class VerySpecialInt(int):
>     pass
>
> and
>
> class VerySpecialIntRenderer(Renderer):
>     pass
>
> this needs to go before the IntRenderer in the mro chain, or at the
> front in the composition example.
>
> Otherwise the dict dispatch would be perfectly ok, and thanks for
> sharing this gist.
>
>
> On Tue, Apr 9, 2013 at 5:32 AM, Joao S. O. Bueno <jsbueno at python.org.br> wrote:
>> On 8 April 2013 23:15, Terry Jan Reedy <tjreedy at udel.edu> wrote:
>>> On 4/8/2013 9:54 PM, Zahari Petkov wrote:
>>>>
>>>> Hello again,
>>>>
>>>> Unfortunatelly, the idea cannot be expressed in the simplest way, since
>>>> this
>>>> leads to confusion, so I present three short gists and explain the case in
>>>> this
>>>> email with a bit more words. I am writing it, since I am confident at
>>>> least it
>>>> will be an interesting read.
>>>>
>>>> All of the three gists present a different implementation of a simple case
>>>> with 4 very simple classes involved.
>>>>
>>>> There are two classes which render instances of types `int` and `float`
>>>> (IntRenderer and FloatRenderer). Imagine similar classes that may render
>>>> any other given type - user classes, a list, etc., but for simplification
>>>> of the case I use only two classes. Each of those classes is instantiated
>>>> with
>>>> a variable and is called to render this variable into a string.
>>>>
>>>> There is an abstract base class (Renderer), which provides the common
>>>> implementation for all the descendants and leaves the `__call__` to the be
>>>> implemented by the concrete classes.
>>>>
>>>> The last, fourth, class is a dispatcher, which has the sole purpose to
>>>> pick
>>>> the right renderer, call it and return the result. We prefer many
>>>> specialized
>>>> classes instead of one big class that may render all types.
>>>>
>>>> The first gist uses composition to achieve that, which would be the
>>>> usual way to do that. The dispatcher iterates, picks the right renderer,
>>>> calls
>>>> it and returns the value:
>>>>
>>>> https://gist.github.com/majorz/5342257
>>>>
>>>> Cooperative inheritance is however also a great pick for such a use case.
>>>> In
>>>> this type of implementation if a subclass cannot do the job (render), it
>>>> will
>>>> delegate the work with super() to the next class in the mro chain.
>>>
>>>
>>> If you inherit from 20 or 100 classes, each attribute access becomes a
>>> substantial linear search. I would forget inheritance and use a dict mapping
>>> class of the object being rendered to the data needed to render it. In your
>>> simple case, the dict would be {int:'INTEGER {}', float:'FLOAT {}'}.
>>
>> Which can easily be conbined with the "one render method per class"
>> writing style you (Zahari)  want with something just like:
>> https://gist.github.com/jsbueno/5342460
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas