[Python-3000] Another overloaded functions usecase
Guido van Rossum
guido at python.org
Fri May 19 17:02:48 CEST 2006
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.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.
>
> _______________________________________________
> 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/)
More information about the Python-3000
mailing list