Re: Multiple dispatch

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Sat, 11 Jun 2011 13:52:05 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Yes, that looks like the usual pattern for protocols and similar stuff,
> when objects do not depend on the container.
What kind of dependencies do you have in mind ? Object existence depending  
on the container ? Or object's properties depending on the container ?

I was trying to figure many cases (in an attempt to invalidate the design,  
and fail with that, to prove this is the good design); among others, this  
one : if the container know enough about the object types because it is  
fully dedicated to these object types, one may argue the container could  
also serialize objects on its own side. However, this would imply a switch  
on object types, which is not clean, due to an implicit though behind  
this: dispatching calls and switch are somewhat similar things, however  
with an important difference, which is that with dispatching calls, the  
corresponding switch is always owned by (under the responsibility of) the  
type on which the switch is to be done, while with the switch approach,  
anything could do a switch. The former more enforce structuring.

Another approach, with a more concrete-like example (which is not the one  
I am actually dealing with… I wont tell more, as I prefer to keep this  
talk as much abstract as possible) : you have two types, one for a  
character string and one for an array of numbers, and two containers. Say  
one container is a file and the other is anything else you wish (could be  
a serial communication wire plugged to some device, as an example). Let  
say there are two way to serialize each type. For the string, there is a  
C-like serialization, that is, all characters first, with a final Unicode  
U+0000, and a Pascal-like serialization, with a length first and then the  
all characters. Let say there is something similar with the array of  
numbers : it could either be serialized with a kind of null terminator,  
and the other way, starting with its length and then its numbers. Say each  
of the two container expect one or the other serialization.

This case seems more ambiguous at first sight, at it could seems as much  
easy and clean to dispatch on either the container or the object. Eh, but  
only one container type know about what null terminators are and only one  
know about what lengths are. Now let say none of the array of numbers or  
the character strings, know about what null terminators are. With such a  
case, wouldn't it be better to dispatch first on the container ? Is that  
the kind of dependency you though about ?


> The opposite case is
> represented by drivers, when objects are maintained by the driver, you
> might first dispatch on the driver type and then on the type of its
> objects.
I tried to figure out this one, but couldn't. Could you tell about a tiny  
and short example ?


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
“c++; /* this makes c bigger but returns the old value */” [Anonymous]