Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>]

Dmitry A. Kazakov wrote:

> This only shows that you provided a wrong C++ example. The right one, i.e.
> corresponding to the case I presented is
> 
> class T
> {
> public:
>    virtual void op() = 0;
>    T (char constraint);
> private:
>    char c;
> };

I don't understand. Your example read

   type T (<>) is abstract tagged limited private;
 private
   type T ( ... constraints ...) is ...

So there is no way for a client to declare an object of type T,
for one thing because there is no way to provide constraints.
Consequenty, a corresponding C++ class T cannot have a public
constructor (I thought).

>>> Probably you refer to
>>> the trick when <> is used to prevent uninitialized objects. But T is
>>> already abstract. You cannot create it in any way.

Yes, from some viewpoint there is overlap in measures
that prevent clients from creating objects of type T.

>> When S is derived from some public T without a (<>),
>> I can name T in S'(T with ...) when T is just abstract.
>> This illustrates that (<>) prevents (meaningful) public derivation.
> 
> No. A meaningful derivation is prevented by the language bug that confuses
> constructors with functions. These two different concepts evidently collide
> when types are abstract.
> 
> You misinterpret the purpose of <>.

How so?  A T(<>) implies that clients cannot explicitly
constrain the set of values in T from (public) outside
when nothing public yields a constrained object.
A declaration, subtypes, derived types or anything
that is not provided by type T(<>) alone is insufficient.
If T is abstract, this is an even bigger sign post.

Why would one want to derive from such a type?

The next thing I will do when seeing such a "restrictive" type
is to look for some factory, or some children.
These may provide constraints and remove restrictions.

> If they did, they would
> also prohibit such *final* types from being abstract. Obviously.

T is not final in T's package hierarchy, is it?
Yes, Ada's O-O type system permits many multiply interwoven effects.
It doesn't look neat, and I guess it is not alway consistent with
definitions external to Ada.