Re: Extension of non-limited type needs limited component

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

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> All that are more or less decoupled things. Why should we tie all of them
>                ^^^^^^^^^^^^
>> under one roof?
> 
> Less, I'd say.  ;-)
> 
> They are all closely related to whether you can copy the thing.

Here we are. Why copying should be tied with:

by-reference vs. not
an ability to have uninitialized objects
an ability to reference objects
inheritance
aggregation
...

All this big variety of possibilities surely influence each other, but this 
does not mean that you can break all this into a simple: 
limited/non-limited.

> To answer my question properly, you would have to explain exactly
> when each of the things I mentioned should be allowed.

I think that it would be better that the properties of an abstract type 
could be specified more directly. Currently we a doing it indirectly and 
very roughly, because the language has its own set of type properties which 
are not well mapped to ADT, for the programmer's point of view. To require 
all objects to be initialized is a damn simple thing. But to achieve this, 
one should make it discriminated! And then, no arrays of the type! Why all 
this? It is because of a wrong idea to control the program semantics. To 
put it very extremely, if a programmer wants to use the character sequence 
":=" for his type, let him do it. It is not the language responsibility to 
make this ":=" semantically correct. The only thing a good safe language 
should do is to make the programmer aware of the consequences. For 
instance, require overriding of the user-defined ":=", in case of 
inheritance. Clarify that ":=" in declarations is not an assignment, but a 
copy-constructor. That ":=" will never be imlicitly used by the compiler to 
copy the components of the type, so if ":=" is defined, then Adjust has to 
be overridden, etc.

> That's not
> easy.  No, I don't expect anybody to do all that work for an informal
> usenet discussion.  ;-)

(:-))

>>...[However, I am afraid, that to correctly deal with it one
>> would need multiple dispatch anyway.]
> 
> I like the idea of multi-dispatch, but all of the languages I've seen
> that support it seem confusing and/or error-prone.

There should be a consistent solution. Otherwise the whole idea of dispatch 
was wrong. [I do not exclude this possibility]

> You need a rule that
> makes it predictable which method(s) will be called in every case.  Not
> just predictable in a formal sense, but predictable by mere mortal
> programmers -- i.e. the programmer's guess should match what the
> compiler actually does.

The major problem I see is a geometric exposion of the methods to be 
overriden. In the case of binary operations it is three methods. If one 
gets overridden then all others shall be too. 

> And you need a way to prevent ambiguities --
> cases where two different methods are "reasonable" should be forbidden,
> preferably at compile time.

This could be done by a requirement of explicit overriding in all cases of 
potential ambiguities, but the consequence is the geometric explosion.

> And you need a way to organize the code --
> with single dispatch, you can put the "methods" with the "type" (or
> "class" or whatever).

Yes, the freezing rules. There is practically no other solution than Ada's 
one: all methods to be declared before the first use. However it is not so 
restrictive as it might look.

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