[Python-3000] Another overloaded functions usecase

[Thomas Dunham]

You're right, that is better - I should have thought of it. 

Thanks,
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 16:03
To: Thomas Dunham
Cc: python-3000 at python.org
Subject: Re: [Python-3000] Another overloaded functions usecase

A classic Python way of doing this would be to extract the type name
from the token and use that for dynamic dispatch on methods of the
builder. This is in a sense "better" because it isn't restricted to
types (could be used to implement HTTP GET/POST/PUT too). Example:

class TEXbuilder:
  def convert(self, token):
    method = getattr(self, "convert_%s" % token.type.__name__)
    return method(token)
  def convert_CHAR(self, token): ...
  def convert_FONT(self, token): ...
  def convert_PARA(self, token): ...

--Guido

On 5/19/06, Thomas Dunham <Thomas.Dunham at reuters.com> wrote:
>
> 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.or
> > g
> >
>
>
> --
> --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%40reu
> te
> 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.
>
> _______________________________________________
> 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.