Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:j0e0l1$5qh$1@tornado.tornevall.net...
> On 07/22/2011 03:59 PM, Randy Brukardt wrote:
>>
>> Given that the problem in question is related to dynamic dispatching and 
>> has
>> nothing in particular to do with extensions, this is an amazing 
>> statement.
>
> My statement was tongue in cheek, intended to express my dislike for 
> tagged types. Their only value seems to be all the traffic here from 
> people who run into problems trying to use them; this would be a much 
> quieter place without them.
>
> Maybe I'm missing something, but it seems to me that all dispatching in 
> Ada is related to extensions. If you have
>
> type T is tagged ...
>
> procedure P (V : in out T);
>
> and you never extend T, then you never get dispatching (in the sense that 
> a call to P results in something other than this P being called). To get 
> dispatching, you have to extend T
>
> type T2 is new T with ...
>
> overriding procedure P (V : in out T2);
>
> Then you can get a single call that sometimes calls P for T and other 
> times P for T2; that's dispatching. I don't know what dispatching means 
> without an extension and an overridden subprogram to dispatch to.

You're right in language terms, but as Dmitry points out, this occurs only 
because we're discussing tagged types (which include 3 of the 4 OOP legs in 
a single package). I was thinking more generally (and yes, I just complained 
about Dmitry doing that); what I was thinking of by "extension" was actually 
adding components to a type, not just deriving a a type with the same set of 
components.

As I was describing, most of the use of dispatching in Claw does not use any 
extension (that is, adding new components), it just changes the behavior of 
the dispatching routines appropriately. So there is only a change in 
behavior, not a change in representation.

Others have pointed out that using case statements as you suggested is 
essentially worthless unless you know every entity that the program is going 
to process before the fact. And real world programs are not like that (I 
have plenty of experience changing hundreds of case statements each time we 
make a change in node types or intermediate code definitions in Janus/Ada).

                                      Randy.



>> OTOH, programming by composition would provide nothing, in that there 
>> would
>> be no way to change the handlers for the base type. One could graft some
>> sort of unstructured mechanism on top of the objects (possibly using
>> access-to-subprograms), but this would provide many more opportunities 
>> for
>> mistakes (if you forget to set the access-to-subprogram value, the 
>> routine
>> might as well not exist).
>
> The equivalent of dispatching in programming by composition is a 
> subprogram that contains a case statement that contains calls to other 
> subprograms. No access-to-subprogram values involved. It does the exact 
> same thing as dispatching, except that it's easier to read and understand 
> and doesn't result in large numbers of "what am I doing wrong?" posts to 
> c.l.a.
>
>> Remember that there are four legs to the OOP stool: strong typing,
>> encapsulation, extension, and dynamic dispatching -- and each of these is
>> orthogonal to the others (shown by the fact that Ada has the first two
>> without even using tagged types, that is OOP). So there is no necessary
>> relationship between extension and dispatching (and working around the 
>> one
>> does nothing to solve a problem that mainly depends on the other).
>
> Again, I have no idea what dispatching even means in the absence of 
> extension.
>
> In Ada, "programming by extension" is achieved by the use of tagged types; 
> it includes dispatching. I have never seen anything implemented using 
> tagged types that could not also be implemented using programming by 
> composition. It follows that if there is a case where tagged types cause a 
> problem, the equivalent solution without tagged types is an effective work 
> around to the problem.
>
> Of course, in the case where there is no solution using tagged types, 
> there may also be no solution without using them.
>
> -- 
> Jeff Carter
> "If you think you got a nasty taunting this time,
> you ain't heard nothing yet!"
> Monty Python and the Holy Grail
> 23