Re: How to test object hierarchy

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Dmytry Lavrov wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:<bs47m5$9e9ea$2@ID-77047.news.uni-berlin.de>... <snip>
>> 
>> I think that IF Ada should have multiple dispatch on different types
> 
> Wao.That's exactly(multiple dispatch) that i tried to explain to
> peoples(very experienced and probably smart too ) who know only
> "object.method" notation.
> Of course that failed(they even can't understand what it is it),
> because that damn "."(like fields in record) left place only for one
> object!
> 
> i got probably good(and also wild) idea that
> method(paramether,paramether,...) are shugar for
> method(composed_class_constructor(paramether1,paramether2,...) )
> 
> and if thete's multiple inheritance, it's
> method(temporary_child_class_constructor(parent1,parent2,...) );
> 
> and also about that it's shugar for
> dispatch(in paramether1[, in paramether2....]).method(in out
> paramether1[,in out paramether2....]);
> - it can be implemented without changing the language at all,but need
> lots of stupid work with "procedural variables".
> 
> Maybe that could give someone here any good idea.
> 
> (it was about problem with overloading math operators for classes-
> double dispathing was required - different methods for matrix by
> matrix,matrix by scalar,matrix by vector,vector by matrix,etc,in all
> combinations including complex number stuff ,etc. )

The case you are describing is multiple dispatch on same type. It is a bit
easier, especially because the existing freezing rules are OK and because
it still allows C++ appoach of having virtual table pointer buried in
objects. I have posted an example how to deal with it. You can also take a
look at

http://www.dmitry-kazakov.de/ada/components.htm

where it is used for "=", "<" operations.

But the pet idea of many OOPLs that methods belong to object is absolutely
wrong. So the prefix notation. The pressure is so high that there is an AI
to introduce it in Ada! (It already exists for tasks and protected objects)

>> then
>> inevitably we should reconsider the freezing rules. The most useful
>> implementations of MD appear when types are defined in different
>> packages. The rationale behind the existing freezing rules is to prevent
>> dispatching to non-elaborated targets. I believe that for a MD operation
>> the freezing point could be the last freezing point of all involved
>> types. For example:
>> 
>> package Devices is
>>    type Device is tagged ...;
>>    procedure Load (X : in out Device);
>> end Device; -- No more primitive operations with only Device
>> 
>> with Devices; use Devices;
>> package Curves is
>>    type Curve is tagged ...;
>>    procedure Show (X : in out Device; Y : Curve);
>> end Curves; -- No more operations with Device and Curve
>> 
>> It is clear that these rules can be very dangerous, if we will not limit
>> use of non-primitive operations (except the class-wide ones). The first
>> step could be to make all types "tagged". But even this could be not
>> enough.
> 
> Main problem that compiler will no longer detect some errors,right?

Errors, undesired overloadings, where overriding was meant, backward
compatibility all that things.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de