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 19:39:44 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 28 Feb 2009 18:19:38 +0100, Georg Bauhaus wrote:
>> 
>>> 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).
>> 
>> You did wrong.
> 
> I'm not sure I did. Why, if I can bother you on a Saturday?

Because the case as I put it reads: the parent type is abstract and
limited, its discriminants are private.

>> T is abstract.
> 
> Yes, so is class T. Also, there is no way to provide
> an initial value for char c that could constrain
> or discriminate the object.

Wrong. C++ constructor can set c as necessary. Private constraints of an
object (rather their equivalents, since C++ does not have unconstrained
types), are to be determined by the constructor. This is absolutely no
problem in C++.

>> Its discriminants is an implementation detail
> 
> Maybe some discriminant is implementation detail but that
> is not for the client to consider. At least when type T(<>) ...
> expresses "Don't mess with T(<>)."

I don't get it, sorry. Please do not try to switch the discussion topic to
interpretations of implied intentions beyond language constructs.

>    type Power_Plant (<>) is abstract tagged limited private;
> private
>    type Resource is (Sun, Dung, Coal, Oil, Uranium);
> 
>    type Power_Plant (Driven_By: Ressource) is ...
> 
> To me, the public view means I should not try do do
> anything that isn't cared for in T's public view.
> 
> I'd want to turn that discriminant into derived types,
> relly, but when I haven't written the package with T in it,
> then I can't rewrite it.
> 
> 
> Can I ask you again why you want to derive a type
> from a "really private"
> type T (<>) is abstract tagged limited private;

Ada standard does not define "really private types." A type may have public
and private views. That has nothing to do with inheritance.

If you are asking why certain things were moved to private parts of a
package, then it is the information hiding principle. Ada was designed in
order to support it. The presented example uses (<>) because the language
requires it when the discriminants appear in the private part. 

For the power plant example consider:

   type Power_Plant (<>) is tagged limited private;
   function Create (Name : String) return Power_Plant;
   function Get_Name (Plant : Power_Plant) return String;
private
   type Power_Plant (Name_Length : Natural) is tagged limited record
      Name : String (1..Name_Length);
   end record;

This design is perfectly legal in Ada 2005. Name_Length is hidden because
it is nobody's business. Later on, this implementation might be replaced
with Unbounded_String or whatever.

Now the implementation of Create goes as follows:

   function Create (Name : String) return Power_Plant is
   begin
      return (Name'Length, Name);
   end Create;

A derived type works fine:

   type My_Plant is new Power_Plant with null record;
   function Create return My_Plant is
   begin
      return (Power_Plant'(Create ("my plant")) with null record);
   end Create;

As you see your assumptions about implied meanings of (<>) are wrong, at
least in Ada 2005. It is OK to have a parent type with (<>) and a
constructing function that constructs the parent as necessary without
leaking any details about the discriminants and other implementation
details of the parent type.

Now, the point is that this model of construction does not work with
abstract types because of fundamental reasons. It is not (<>) which is
broken, but the construction model.

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