Re: Operation can be dispatching in only one type

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

On Wed, 18 Nov 2009 08:39:14 -0800 (PST), Adam Beneschan wrote:

> On Nov 18, 1:46�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
> Again, although I can see that someone might want to derive ASCII_Text
> from Plain_Text, it wasn't something I considered at the time since it
> wasn't germane to the type of problem I was running into.

So, in effect you want a depth-1 hierarchy, like we have for the protected
interfaces?

>> Consider again ASCII_Text derived from Plain_Text. Let we also derived from
>> Plain_Text_Region and Plain_Marker:
>>
>> � �Plain_Text <-- ASCII_Text
>> � �Plain_Text_Region <-- ASCII_Region
>> � �Plain_Marker <-- ASCII_Marker
>>
>> Now, my concern is what happens with Move_To called on
>>
>> � �ASCII_Text, Text_Region, Plain_Marker
>>
>> You say, it is Constraint_Error. The question what is the reason for this?
>> I don't see any. It is for the programmer to decide.
>>
>> I you say the language forbids that, I say OK, but then that MUST be done
>> static.
> 
> I don't see a practical reason why that would be necessary.  And I
> have a major objection, at least to what I think you're proposing.
> Suppose someone at some organization declares a package with some
> abstract types.  Another organization is developing a large
> application.  Since this is a large application, it's divided into
> several parts with one part being given to one team, another part to
> another team, and so on, working independently.  The idea is that as
> long as each team can develop its part of the application that works
> according to some "contract", then you should be able to put the
> pieces together and get the whole thing to work.  Suppose that two or
> three of those teams decide to use this library package and derives
> child types from those abstract types.  This shouldn't be an issue for
> teams working independently, but your idea would make it an issue,
> because in order for the program to compile, you would require that
> somebody write useless versions of the inherited operations for every
> possible combination of derived types, even when the derived types
> come from two different teams working independently.  Sounds like a
> needless burden to me.

No, it is not a burden it is a mere consequence of a decision made earlier.
If the abstract types are Printer and Contents with the joint operation
Print (the classic example of MD), you *have* to implement all
combinations. It is not a question. The question is how to make the
language helping us in doing this work safely and efficiently.

I have no idea how to do this while keeping it modular. But that does not
change the fact that all combinations have to be defined. To silently
define some of them as Constraint_Error is a very bad idea for the language
like Ada.

>> What I find totally inappropriate for a language like Ada is:
>>
>> 3. Dynamic constraint with run-time checks dropping arbitrary exceptions.
>>
>> I think we should have learnt something from the "accessibility checks
>> disaster".
> 
> OK, I don't understand this.  First, I don't understand what about
> accessibility checks was a disaster;

Because they are the major contributor to hours spent on debugging
unhandled exceptions.

> and second, I don't see what's
> wrong with runtime checks in cases where it's too hard for a compiler
> to figure out at compile time whether something will go wrong.

Accessibility checks are known for being false positive. Same with MD, it
is not a semantic error to cross types in an operation. It is an
*artificial* error introduced by the language designer, because it would be
too difficult to do it otherwise (e.g. right (:-)). Then the very same
designer finds his own error too difficult to detect at compile time! I
have no problem with the former, but do not accept the latter.

> Is
> this another case of letting the perfect be the enemy of the good
> enough?

There exist lots of imperfect languages already. But Ada must be perfect!
(:-))

Returning to the case where we do not want cross combinations. I thought
about it and came to the conclusion that this is single dispatch (tags are
synchronous). I think we should approach this differently.

Let us consider an example were dispatching table is semantically
"diagonal":

   type Object is limited interface ...;
   type Handle is interface ...;

Each time we derive from Object, we want a new Handle. This is IMO a better
example than Document x Region x Marker.

Note that here the issue of packages is especially important. Most likely
we wanted to place Objects into private packages, making only Handles
public.

Most operations on Object and Handle are same and have only one controlled
argument. I am tempted to say that Handle should also implement Object.

   type Handle is interface and Object ...;

But there are two cross operations:

   function Ref (X : Object) return Handle is abstract;
   function Target (X : Handle) return access Object is abstract;

The same problem more complicated. How to add

   type Readonly_Handle is interface ...;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de