Related articles |
---|
[8 earlier articles] |
Re: Implementation Language Choice gdr@integrable-solutions.net (Gabriel Dos Reis) (2004-02-27) |
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-03-02) |
Re: Implementation Language Choice la@iki.fi (Lauri Alanko) (2004-03-02) |
Re: Implementation Language Choice lex@cc.gatech.edu (Lex Spoon) (2004-03-02) |
Re: Implementation Language Choice torbenm@diku.dk (2004-03-06) |
Re: Implementation Language Choice bettini@dsi.unifi.it (Lorenzo Bettini) (2004-03-06) |
Re: Implementation Language Choice joachim.durchholz@web.de (Joachim Durchholz) (2004-03-11) |
Re: Implementation Language Choice mayan@sandbridgetech.com (Mayan) (2004-03-19) |
Re: Implementation Language Choice Barak.Zalstein@ceva-dsp.com (Barak Zalstein) (2004-03-26) |
From: | Joachim Durchholz <joachim.durchholz@web.de> |
Newsgroups: | comp.compilers |
Date: | 11 Mar 2004 12:46:36 -0500 |
Organization: | Oberberg Online Infosysteme |
References: | 04-02-109 04-02-149 04-02-164 04-02-174 04-03-014 04-03-029 |
Keywords: | OOP |
Posted-Date: | 11 Mar 2004 12:46:35 EST |
Lorenzo Bettini wrote:
>
> I think in these cases the best thing would be to have double
> dispatch in the language,
Note that double dispatch doesn't solve the extendibility problem
that's inherent in such situations, it just moves it from technical
context to social context (which doesn't make it easier to solve).
I.e. if you have NxM possibilities, it's easy to keep the N
possibilities extendible, and it's easy to keep the M possibilities
extendible, but you get into trouble as soon as you try to keep both
extendible. You get into technical difficulties (module independence,
or method selection strategies that will break in some cases) and/or
social difficulties (if those who are responsible for extending in the
N direction are different from those of extending in the M direction -
imagine than N is hardware variants offered by IBM and M is software
variants offered by Microsoft and you'll see what I mean).
Oh, and preprocessors are evil (they don't compose).
:-)
Regards,
Jo
--
Currently looking for a new job.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.