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

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

On Sat, 28 Feb 2009 16:36:43 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> Exactly. This is why a user of public T must be able to construct T knowing
>> nothing about the discriminants of T.
> 
> I meant to say that the derivation should not work in the
> following sense. T being (<>)ed, abstract, and limited means,
> clients are supposed to not even try to create objects of this
> type.

It does not create T. It does S.

(an inherited from T part of S is constructed as required by the designer
of T. No any object of T is created. T is abstract.)

>>>> Remember? Constructor is not function. It never will. See the problem?
>>> Assuming C++ has constructors, will your arguments apply
>>> in the following examples (just trying to understand):
>>>
>>> class T
>>> {
>>> public:
>>>   virtual void op() = 0;
>>> private:
>>>   T(char constraint) : c(constraint) {}
>>>   char c;
>>> };
>> 
>> No, the constructor in the example must be public.
> 
> The constructor is private because T(<>) has private
> constratints only. IOW, clients cannot construct
> an object either of class T (C++) or of type T(<>) (Ada).

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;
};

>> 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.
> 
> 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 <>. If Ada designers wished to prevent
derivation from T(<>), they would simply do it. If they did, they would
also prohibit such *final* types from being abstract. Obviously.

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