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:
> 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?

> 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.

> 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(<>)."

   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;