Re: Generics vs. Message passing: object namespaces

On 2007 Feb 23, at 10:47 PM, [email protected] wrote:

>> If you object to (image:draw obj1 ...) vs. (holster:draw obj2 ...)
>> because having to indicate the 'source' of draw you wish to invoke is
>> wordier, I agree with Pascal on that. Yawn. I'd rather see the intent
>> made clear in ambiguous cases (and hence this is applicable to
>> Pascal's Java MI example), for I have much more powerful ways to
>> condense my code than saving one word by extracting the type of obj1/
>> obj2.
>
>     I think you mistakenly trivialize the issue at hand by
> misunderstanding it as a complaint about terseness.  If we are to go
> down that (specious) road, you will not have to go far to find dynamic
> typing sceptics that would prefer all types be explicitly stated, just
> to make things clear.

Not types, type hierarchies. You know full well that "draw" in the  
"image concept space" has parameters that are different in meaning  
from the parameters to "draw" in the "holstered things concept  
space". No amount of name-space magic is going to alleviate you from  
having to know which sort of 'draw' you are intending to invoke.


>     Whether to use generic or object dispatch is a fundamental  
> language
> design decision that affects the entire structure of the object
> system.  Which one is better is of serious concern.  No language
> feature today can escape the question of scalability, as software is
> not getting simpler and smaller over time.  If generic dispatch has a
> flaw that becomes more apparent as software systems get more complex,
> it is not a viable option for future language designs.

You seem to see the generic dispatch as a problem only because you  
insist that 'image draw' and 'holster draw' pun to the same bare  
symbol 'draw'. ... That somehow the world of increasing scalability  
admits of no name space management beyound object dispatch? ... That  
somehow we'll have, what, dozens of 'draw' methods in the same code  
and that we'll pierce the scales of complexity because we'll "know"  
the types of the objects to which we are applying these eponymous  
methods with abandon?

Pascal has already shown that this is really about name space  
control. None of us are saying that 'image:draw' should be  
'triangle:draw' or 'square:draw' or 'polygon:draw' or 'circle:draw'  
because we all know that the nature of that draw is what matters, not  
any specific implementation.

You seem to be insisting that we can't tame complexity unless saying  
'object_h.draw' gets a holstered draw while saying 'object_i.draw'  
gets an image draw, because saying (holster:draw object_h ...) or  
(image:draw object_i ...) doesn't scale?

I don't see your point. If there are ten or a hundred, or just five  
different kinds of draw methods all congregating in one function/ 
module/subsystem, what you have to manage is the mental burden of  
keeping track of them. Object dispatch isn't going help, because not  
writing x:draw doesn't save you _from needing to know that it is x's  
draw you want to invoke_.

We seem to be at an impasse. You seem to be insisting that object  
based dispatch scales "better" and that generic dispatch has to be  
without any name space control and so doesn't scale. And "we" are  
unsuccessful at convincing you to let go of the local maxima of  
object based dispatch for a much more powerful mechanism , and the  
issue seems to be unconvincing because you have to deal directly with  
the name space issue.

Put another way: As Pascal and others have pointed out, the dynamic  
dispatch that doesn't favor on particular parameter over all the  
others is a huge win. But yes, that means you have to abandon the  
apparent "free" name space dispatch. But that is just a local maxima.  
Perhaps one has to experience a richer dispatch in a non-trivial  
environment to to understand that. (see previous message link re:  
Blub paradox).

			--Doug