🚀 go-pugleaf

In article <259400003@inmet> stt@inmet.inmet.com writes:
|
|Re: Separate Decl of Private Member Fcn
|
|I wrote:
|
|>>The obvious solution to the concerns about allowing
|>>member functions to be added after the end of the class
|>>declaration is to require that they be private and static.
|>>This makes them visible only to the other member functions,
|>>and prevents "hijacking."
|
|Ron Guilmette wrote:
|
|>I generally agree with Tucker's comments, except that I believe that what
|>he probably meant to say was that it should be allowable to add private
|>*non-virtual* functions after the end of a class.
|>
|>I don't see how the static-ness of a member function should be an issue when
|>it comes to adding member functions after the end of the class.
|
|I agree than non-virtual would probably be adequate, but not as safe as static.
|Static implies non-virtual, but it also prevents
|"hijacking" of inherited (though non-virtual) member functions.

An earlier article in this thread mentioned that adding member functions
after the end of a class was very useful in ADA programs.  However, ADA's
``derived'' types can only restrict the values that may be assigned to
members that already exist in the parent type.  There is no notion of
adding new members in the derived type.

So, what does the ability to add member functions after the end of an existing
class buy you that simply deriving another class from the existing class
could not?  Especially given the confusion that could result from different
member functions being independently added to the same class in different
translation units of the same program...