Related articles |
---|
Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-05) |
Re: Best multimethods/multiple dispatch implementations? FSet.SLB@gmail.com (Scott Burson) (2008-09-05) |
Re: Best multimethods/multiple dispatch implementations? mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-09-06) |
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-08) |
Re: Best multimethods/multiple dispatch implementations? sh006d3592@blueyonder.co.uk (Steve Horne) (2008-09-09) |
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-15) |
Re: Best multimethods/multiple dispatch implementations? gneuner2@comcast.net (George Neuner) (2008-09-15) |
Re: Best multimethods/multiple dispatch implementations? sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-17) |
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-18) |
Re: Best multimethods/multiple dispatch implementations? bettini@dsi.unifi.it (Lorenzo Bettini) (2008-09-18) |
Re: Best multimethods/multiple dispatch implementations? gneuner2@comcast.net (George Neuner) (2008-09-19) |
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-22) |
Re: Best multimethods/multiple dispatch implementations? gneuner2@comcast.net (George Neuner) (2008-09-24) |
Re: Best multimethods/multiple dispatch implementations? armelasselin@hotmail.com (Armel) (2008-09-24) |
[8 later articles] |
From: | Stephen Horne <sh006d3592@blueyonder.co.uk> |
Newsgroups: | comp.compilers |
Date: | Wed, 17 Sep 2008 19:05:05 +0100 |
Organization: | virginmedia.com |
References: | 08-09-026 08-09-051 |
Keywords: | OOP |
Posted-Date: | 17 Sep 2008 17:57:06 EDT |
On Tue, 09 Sep 2008 16:25:38 +0100, Steve Horne
<sh006d3592@blueyonder.co.uk> wrote:
>Actually, thinking about it, there is a virtual-table method that can
>handle multiple dispatch and separate compilation. In a sense, it's
>already in quite common use, though as a design pattern rather than
>as a compiler feature. Dispatch requires a table lookup for each
>polymorphic parameter. The design-pattern version uses a polymorphic
>method for each polymorphic parameter, so that the multiple dispatch
>is resolved using a series of single dispatch calls. Each method
>calls the next in sequence (with a different parameter as 'this')
>until you get to the final fully-resolved method.
I withdraw this - the flaw isn't overhead (in a language that compiles
the pattern, the intermediate calls would be eliminated in favour of
simple vtable-to-vtable lookups). The flaw is that every class needs
to know about every other class from the start, and also needs some
idea of the dispatch decision beyond it's own immediate interest.
The chain of calls is basically a precompiled decision tree, generated
manually be the programmer.
Don't feel so bad now that I've realised that.
From what George said, I suspect what my utility is doing as a code
generator is a slow and overcomplicated variant of what CLOS and Dylan
do on a first-use basis at run-time.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.