Topic: proposal: constant inheritance


Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 6 Jan 2003 03:10:24 +0000 (UTC)
Raw View
philippe_mori@hotmail.com ("Philippe Mori") wrote in message news:<s77R9.5279$VW5.1029582@news20.bellglobal.com>...
> > Hi people: I'd like to ask you about another proposal.
> > The idea is the ability of inheriting constantly from a base class:
> > the 'const' keyword in the base classes list:
> >
> > class X: public const Y {...};
> >
> > what would have the following implicances:
> >
> > 1) this becomes const each time it is upcasted
>
> This seems fine to me. This is what someone would expect.
>
>
> > 2) only 'const' methods of X may supermessage Y's methods
>
> I am not sure what you want to say... I do think that both const and
> non-const method of X could call only const method of Y (this is implied by
> 1).

You are exactly right, I wanted to say so: only const methods of Y can
be called from X. Sorry about that.

>
> And I do think that it should be possible to override a non-const virtual
> method of Y in X provide that the overriden method do not call the non-const
> method of Y... In fact, the derived non-const method would not be callable
> from the base (since it is const) but it would be callable directly (as
> other non-const method). Maybe, this could break the type-system in some way
> (i.e. allows to do something that should not be allowed) but I do not see it
> right now.

Neither me. And I absolutely agree that Y's const virtual methods
should be able to be overriden in X.

>
> Maybe we may force override method to be constant but I think it is a bit
> restrictive unless we proove that it broke the type system... For me, it is
> essentially the same as adding any unrelated member function.
>
agree.

> Also, it would be impossible (in typical cases) to allows assignment since
> this would require to modify the base (generally) but the base is const and
> should not be modified.

Yes, this would act as a protection mechanism.

>
> > 3) Y's attributes are constant for any access of X
>
> That seems fine to me. This is what I expect.
>
>
> >
> > Please let me know your opinions
>
> I am not sure of the utility of this. If the base class is const, maybe you
> should derive privatly from it (in that case, only the derived class would
> have to avoid using non-const stuff). And it would be event easier to\

Ok, but I thought this specially for 'public/protected' inheritances;
remember that the inheriting class can also be 'used' (contained or
inherited):
suppose you have a proxy class, with two sets of methods: const, and
non const:

class WorldProxy
{
public:
     void destroyWorld(void);
     size_t getAge(void) const;
};

and an 'innofensive' wrapper:

class MyProxy : public const WorldProxy
{
...
};

So, if MyProxy is used, inherited/contained, only 'innocent' methods
will be accessed and the world will remain safe.

Same thing with supermessaging with virtual methods of the base class.

> enforce const access if the base is replaced by a member (if you need to
> overide some virtual functions, then you may add a class that would forward
> calls to the outer object).
>

exactly.

Excelent the quality of your feedback (and corrections), thanks
because it was useful.

 Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Sat, 4 Jan 2003 00:23:42 +0000 (UTC)
Raw View
> Hi people: I'd like to ask you about another proposal.
> The idea is the ability of inheriting constantly from a base class:
> the 'const' keyword in the base classes list:
>
> class X: public const Y {...};
>
> what would have the following implicances:
>
> 1) this becomes const each time it is upcasted

This seems fine to me. This is what someone would expect.


> 2) only 'const' methods of X may supermessage Y's methods

I am not sure what you want to say... I do think that both const and
non-const method of X could call only const method of Y (this is implied by
1).

And I do think that it should be possible to override a non-const virtual
method of Y in X provide that the overriden method do not call the non-const
method of Y... In fact, the derived non-const method would not be callable
from the base (since it is const) but it would be callable directly (as
other non-const method). Maybe, this could break the type-system in some way
(i.e. allows to do something that should not be allowed) but I do not see it
right now.

Maybe we may force override method to be constant but I think it is a bit
restrictive unless we proove that it broke the type system... For me, it is
essentially the same as adding any unrelated member function.

Also, it would be impossible (in typical cases) to allows assignment since
this would require to modify the base (generally) but the base is const and
should not be modified.


> 3) Y's attributes are constant for any access of X

That seems fine to me. This is what I expect.


>
> Please let me know your opinions

I am not sure of the utility of this. If the base class is const, maybe you
should derive privatly from it (in that case, only the derived class would
have to avoid using non-const stuff). And it would be event easier to
enforce const access if the base is replaced by a member (if you need to
overide some virtual functions, then you may add a class that would forward
calls to the outer object).

And if you need public access, you may add accessor and/or conversion to X
class so that you may access Y type base or sub-object.

>
> thanks!
>   Daniel
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Thu, 2 Jan 2003 19:23:29 +0000 (UTC)
Raw View
Hi people: I'd like to ask you about another proposal.
The idea is the ability of inheriting constantly from a base class:
the 'const' keyword in the base classes list:

class X: public const Y {...};

what would have the following implicances:

1) this becomes const each time it is upcasted
2) only 'const' methods of X may supermessage Y's methods
3) Y's attributes are constant for any access of X

Please let me know your opinions

thanks!
  Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Thu, 2 Jan 2003 21:26:11 +0000 (UTC)
Raw View
In article <23478c42.0301021003.3970a9b2@posting.google.com>,
"danielgutson@hotmail.com" <danielgutson@hotmail.com> writes
>Hi people: I'd like to ask you about another proposal.
>The idea is the ability of inheriting constantly from a base class:
>the 'const' keyword in the base classes list:
>
>class X: public const Y {...};
>
>what would have the following implicances:
>
>1) this becomes const each time it is upcasted
>2) only 'const' methods of X may supermessage Y's methods
>3) Y's attributes are constant for any access of X
>
>Please let me know your opinions

You have the cart before the horse. Please explain what real world
problem this would solve. All proposals for change or extension must
show that they meet a genuine need.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]