From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: Redispatching Date: Thu, 17 Apr 2014 10:53:38 +0200 Organization: A noiseless patient Spider Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> <1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net> <17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net> <1wjmcbk375lzk.6o7dpqcp3va3.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 17 Apr 2014 08:53:38 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="23dab0694e4174fdc880833ec67fa650"; logging-data="5361"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Eq2pV6jrLThpzyT8QVfX3" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: Cancel-Lock: sha1:wnmZqmv0KjTBAbPoEETookRlTOM= X-Enigmail-Version: 1.6 Xref: news.eternal-september.org comp.lang.ada:19348 Date: 2014-04-17T10:53:38+02:00 List-Id: Le 16/04/2014 21:53, Niklas Holsti a écrit : > On 14-04-16 12:30 , J-P. Rosen wrote: >> Actually, it's a different use case. Not much discussed in the >> litterature, because only Ada has a clear distinction between methods >> (primitive operations) and class-wide operations. >> >> A method is for the case where each type has its own way (method!) of >> doing things: you don't paint a button like you paint a text. >> >> A class-wide operation is usually a combination of (dispatching) calls >> to methods, to build higher level services; it's for the case where you >> want to make sure that all objects use the same algorithm; > > I understand this difference (as should have been evident from my > previous posts). But you are presenting it as a black-or-white, > two-valued choice; in my perception, there are also operations which > share features of both extremes. Shades of grey. In a well organized program, I tend to avoid grey, and match my needs either to one or the other. It is constraining sometimes, but makes understanding and maintenance a lot easier. >> for example, >> when you move a widget, you want to guarantee that it is erased from its >> current position and repainted somewhere else, and that nobody will >> redefine move to do something else! It also ensures that should the >> algorithm change, the change needs to be done in only one place. > > But then I derive a widget type which is implemented by a sprite, and > this widget can be moved just by changing its (x,y) registers, without > "erasing" and "redrawing". The "universal" move operation is not really > applicable to this widget, and can be overridden by a special and faster > operation. (I know that sprites are no longer used in display HW, but I > did not want to invent a more up-to-date example.) Interesting example... If you consider that various widgets have different "methods" of moving, then you have to make it a method and not a class-wide operation. Those that are not sprite would inherit the method from the root widget, i.e. the default erase-and-redraw. >> As far as redispatching is concerned: since a method is linked to a >> single class, there should be no redispatching. > > (I think you meant to write "linked to a single type", not "class".) I use "class" because I'm talking about the general concept, not specifically Ada. #define class "A package declaring a single tagged type and associated primitive operations" ;-) > Then you must also be of the opionion that there should be no > inheritance of methods, because inheritance makes the same method become > linked to different types. Is that your view? > Not at all. I view inheritance of methods as providing a default value for the operation. If you like it, take it, if not, redefine it. However there is still one method per class, whether redefined or inherited. >> Feeling a need for >> redispatching in a method is often a symptom that a class-wide operation >> is a better fit. > > Except in these intermediate cases where there is an operation which is > an almost general, default algorithm, which could be class-wide except > that it needs to be overridden for some types in the class. See above. The choice is a design decision, and often not an easy one. But there is value in deciding "this is a property of each specific type" or "this is a property of the whole class (in the sense class-wide)". [...] > I'm not advocating redispatching in general, but I don't hesitate to use > it when it is necessary to give me the behaviour I want. To me, it raises an alarm that something might be wrong. A possibility is that the functionality could be kept class-wide by adding another method. Admitedly, that's MY way of working: define a few (sometimes constraining) patterns and stick to them. Similar to my preference for standard components (even if I have to adjust my design), rather than reinventing the wheel if the standard components do not match 100%. YMMV. > And I refuse to feel ashamed just because C++ or Java users also use > redispatching. > Nothing to be ashamed of, it is a matter of philosophy of software design. What I'm saying is just that Ada has a richer toolset than these languages, therefore the fact that other languages use a certain solution does not imply that the same should be used for Ada. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr