[Python-3000] Another overloaded functions usecase

[Thomas Dunham]

The slides are titled Multimethods, Pattern:Builder and Pattern:
Builder with Multimethods.
http://norvig.com/design-patterns/img025.htm to img027.htm.

Choosing the correct action always depends on two things: what you are
converting and what you are converting it to. If you use multiple
dispatch the language makes this choice in one go. If not the language 
makes half the choice based on the class of the builder and the
programmer 
has to maintain a dictionary of functions to make the other half. A side
benefit is using multiple dispatch makes each function's intent more
clear (IMO).

It looks dumb to pass an object and one of it's properties, but that's
needed to be able to say "call the implementation of convert that
encodes this token (that is a character) for TeX" in one call. I agree
your API is better, I'd likely end up with this:

def convert(token, target):
    convert(token, token.type, target)

I'm pretty sure that would be OK. It looked a bit odd to me at first
because it would TypeError on the arguments nowadays, but that seems
like an incorrect reflex.

Tom



-----Original Message-----
From: python-3000-bounces+thomas.dunham=reuters.com at python.org
[mailto:python-3000-bounces+thomas.dunham=reuters.com at python.org] On
Behalf Of Guido van Rossum
Sent: 19 May 2006 05:36
To: Thomas Dunham
Cc: python-3000 at python.org
Subject: Re: [Python-3000] Another overloaded functions usecase

Which slide in Norvig's presentation are you referring to?

Why would you have to pass token.type to convert()? I'd think that the
simplest API would be

  convert(token, target).

What am I missing?

--Guido

On 5/18/06, Thomas Dunham <thomas.dunham at gmail.com> wrote:
> Talk on overloaded functions seems a bit sparse recently, and as I 
> rather like the idea I wondered if another usecase would be helpful. I

> reworked this from an example published 10 years ago by someone who a 
> couple of you guys might see at lunchtime.
>
> Say we want to read a text document in RTF and convert to one of many 
> formats. The gang of four describe a builder pattern to do this, and 
> their approach requires a class for each type of object to build, and 
> another for the director. It's likely that you'd ditch the director if

> you were writing in Python:
>
> class TEXConverter(TextConverter):
>   def convertChar(token):
> ...
>
> builder = TEXConverter()
> ...
>
> act = dict(
>     CHAR=builder.convertChar,
>     FONT=builder.convertFont,
>     PARA=builder.convertParagraph
> )
>
> t = get_token()
> act[t.type](t)
>
>
> Maybe with overloaded functions it could look like this:
>
> target = TEXText()
> Font, Para, Char = inputTypes()
> ...
> token = get_token()
> convert(token, token.type, target)
> ...
> def convert(token, type:Font, target:TEXText):
>     ...
>
> def convert(token, type:Para, target:TEXText):
>     ...
>
> def convert(token, type:Char, target:TEXText):
>     ...
>
> In the original (written in Dylan) Font, Para, Char are instances, and

> it uses == to dispatch on individual objects. I'm suggesting creating 
> more classes and dispatching on (possibly singleton) instances of 
> them. (The origonal is here: http://norvig.com/design-patterns/)
>
> I don't think this is as elegant as Norvig's version, but I do like 
> the way it makes the language do all the dispatching, and looking at 
> the function prototypes gives a good impression of the type/operation 
> grid that is somewhat hidden in the single-dispatch version.
>
> Tom
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000 at python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/thomas.dunham%40reute
rs.com


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.