On Fri, May 17, 2019 at 6:09 PM Matthew Woehlke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 17/05/2019 05.23, Ofri Sadowsky via Std-Proposals wrote:
> > This post is based on an experience which, I believe, is shared by many,
> > having to do with the concept of "extending" a base class rather than
> > "overriding" its functionality. [...]
> >
> > In current language [...] it requires the developer to explicitly
> > make the call to the base class method, with the risk of missing it.> In
> principle, the existing compiler mechanism could also support
> > something such as the following. [...]
> >
>
> I think the fact that you are already proposing two different mechanisms
> for this hints at why this is problematic and, IMHO, unlikely to go
> anywhere. The trouble is, you're handling the fairly common cases, but
> what about the less common cases? What about if the overriding method
> needs to use neither of those patterns or, worse, needs to call the base
> method conditionally?
>

True, these are the common cases, but nevertheless, something along these
lines can be helpful.

Consider the even more complicated and, well, disagreeable, case of
multiple inheritance with the diamond pattern, virtual inheritance and
all. If the final derived class calls its two (or more) bases, and each in
turn calls the shared base, then the shared base is called twice while in
reality it should have been called once. An automated generation of the
call sequence could remedy this.

I am proposing two mechanisms for these common cases in the hope that this
is where it stops. Had there been more than two cases, then the idea does
seem somewhat futile. But IMHO these two cases are common enough and
important enough to look at anyhow.

For the rest, unfortunately, I don't have a better offer than using the
existing virtual method mechanism as is. I don't see a way to generalize
beyond the two.



>
> I think it would be much more productive to pursue a de facto mechanism
> to mark a virtual method for which the base implementation should always
> be called, and for the compiler to issue a warning if it is not.
> Possibly this should be combined with an annotation to indicate
> intentionally not calling the base method.
>

My goal is that the "extensible" nature of the method would be _declared_
at the base class. Being declared, the question of whether to issue a
warning is almost secondary. Because, as many of us treat warnings as
errors, we'd have to solve the issue of missing the explicit call one way
or another. By that time, we'd beg for an automatic solution.



>
> This *might* be combined with a new syntax to make it easier to invoke
> the base method (including argument forwarding), though the committee
> tends to be resistant to such things without overwhelming motivation.
>

I would not say it's overwhelming, but the issue with the diamond pattern
does look to me like a stronger motivation.



>
> > Second: It sometimes happens that I want to extend an existing class
> > with functionality only [...] the extending class cannot define new
> > members (maybe more relaxed for static members), and in return it
> > does not have to specify all the mechanism of construction and
> > assignment, which is inherited from the base class.
>


> Conversely, I've run into this on multiple occasions. I think this could
> be useful, and should probably be pursued as a separate proposal.
>

These, indeed, are two different issues. To me, actually, the first looks
more acute. But I might split a proposal if it becomes such.



>
> --
> Matthew
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Ofri Sadowsky, PhD
Computer Science Consulting and Training
7 Carmel St., #37
Rehovot  76305
Israel
Tel: +972-77-3436003
Mob: +972-54-3113572