XPost: alt.os.development   
   From: mailbox@dmitry-kazakov.de   
      
   On Thu, 23 Feb 2006 16:16:15 +0300, Maxim S. Shatskih wrote:   
      
   > What is a better desing in my case? Like - you have the virtual methods   
   > GetColor and Paint, and want to allow to override both of them, so that the   
   > "simple" descendant will reuse the base's Paint but have overriden GetColor,   
   > and the "complext" descendant will override Paint itself and possibly not use   
   > GetColor at all.   
      
   Isn't this an example of fragile class design? The user of Paint should   
   know something special about inherited Paint, which is not in the contract   
   of. Interaction between color and painting is not specified. Is it the   
   color used for painting, in all descendants? If not, then in which and   
   when? Depending on the answer, the color could be made an independent   
   object (argument for Paint, member of the object). The parts of Paint   
   independent on color could be factored out and represented as methods to   
   override, while Paint itself would be class-wide. There is also a suspicion   
   that it is better to be something like:   
      
   Paint (X : Brush; Y : Color); -- "virtual" in Brush and Color   
      
   I.e. multiple dispatch again. If so, then it is not re-dispatch, but   
   cascaded double dispatch: first you check for Brush, then for Color.   
      
   And finally if you really need it, I would force the programmer to declare   
   the root type as having self-identity.   
      
   >> 1. You need a type tag (vtab pointer) allocated in specific objects   
   >   
   > Is it possibly _at all_ to have polymorphic objects without having per-object   
   > metadata?   
      
   No. But because T and T'Class are formally different types, then for small   
   objects without identity, you can let them have different representation.   
   So Boolean will remain exactly one bit long, while Boolean'Class will   
   consist of type tag + the bit. Large objects and ones always passed by   
   reference could have T and T'Class sharing the representation, this is how   
   C++ does.   
      
   >> 2. You have unnecessary performance hit in specific methods decomposed into   
   >> other methods. Because each internal call is dispatching.   
   >   
   > Dispatch in C++ is a neglectable performance hit, especially on modern CPUs.   
   > "call [ecx]" vs. "call 0x01347f00" have the same speed, maybe call [ecx] is   
   > even faster due to lesser fetching.   
      
   Not quite, you forgot about inlining and other optimizations impossible for   
   late method bindings.   
      
   >>Assignment is a classical example of a multi-method.   
   >   
   > What book can you recommend on the underlying theory of all of this, where   
   the   
   > terms of "dispatch", "multi-method", "covariant" in terms of function   
   > parameters and such are defined?   
      
   Good question. There is no established theory of types capable to describe   
   all existing programming languages, explain and predict their problems.   
   This is the major problem in my view. People are disagree on even what is   
   "value", "object", "type", "class". So you should take with a grain of salt   
   everything anybody writes. For example, the point of view, I represent,   
   requires values, types, types of types, types of types of types, etc all be   
   separated [motivation is Russell paradox.] I.e. type can't be a value of   
   itself (no pun intended (:-)) There is another school, which tries to make   
   everything a first-class object. You find no agreement on that, until a   
   solid theory will emerge. Then there is the functional camp, they make some   
   valid points too. Anyway, look for Luca Cardelli; Liskov & Wing (infamous   
   LSP)   
      
   >> Yep. If T and T'Class are different types, then they should have different   
   >   
   > What does the term "T'Class" means? "T or any, possibly indirect, descendant   
   of   
   > T"?   
      
   That is the set of types rooted in T: {T, T1, T2, T3, ...}. The closure of   
   this set is a new type which values are [equivalent to] ones of these   
   types.   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)