In article <D23t1y.F5y@news.cis.umn.edu>
           milor001@maroon.tc.umn.edu "R A Milowski" writes:

>I have been working on a class library that uses rather large ABC to implement
>an abstract protocol.  In some instances (not mine) I could see a user of this
>library wanting to implement only a subset of the ABC's virtual functions.
>Thus, to do so, they would have to create "dummy" functions that just do
>nothing.
>
>I would be nice to be able to derive a class from the ABC and indicate to the
>compiler that certain virtual functions just don't exists and so it shouldn't
>call them at run time.  I could see this being implemented by some kind of
>flag (or non-existant function pointer) in the virtual function tables.
>
>So, now the questions:
>
>1. Is there some way I can design around this (other than breaking up my
>   ABC into smaller classes)?

/1/ provide default no-op, abort or throw behaviour

/2/ break the ABC up into smaller classes :-) - is there something else
 in your design that prevents you from doing this?

>2. Does this sound reasonable?

No, not really I'm afraid and I don't believe that any new language features
should be added to accommodate this style.

The problem appears to be the granularity of your protocol ABC: it's too
course. If partial protocols are meaningful then they should be the
starting point and not the whole protocol - as you've discovered, breaking
a monolithic class will be tough on derived classes.

Hope this helps.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

I have been working on a class library that uses rather large ABC to implement
an abstract protocol.  In some instances (not mine) I could see a user of this
library wanting to implement only a subset of the ABC's virtual functions.
Thus, to do so, they would have to create "dummy" functions that just do
nothing.

I would be nice to be able to derive a class from the ABC and indicate to the
compiler that certain virtual functions just don't exists and so it shouldn't
call them at run time.  I could see this being implemented by some kind of
flag (or non-existant function pointer) in the virtual function tables.

So, now the questions:

1. Is there some way I can design around this (other than breaking up my
   ABC into smaller classes)?

2. Does this sound reasonable?

3. If implemented, would it be more efficient, as efficient, or worse?


==============================================================================
R. Alexander Milowski, SGML Operations Manager    milor001@maroon.tc.umn.edu
Microcom Inc.                  (612) 825 - 4132   "An SGML Solutions Company"
==============================================================================

milor001@maroon.tc.umn.edu (R A Milowski) writes:

>I have been working on a class library that uses rather large ABC to implement
>an abstract protocol.  In some instances (not mine) I could see a user of this
>library wanting to implement only a subset of the ABC's virtual functions.
>Thus, to do so, they would have to create "dummy" functions that just do
>nothing.

Or indicate some sort of error.

>I would be nice to be able to derive a class from the ABC and indicate to the
>compiler that certain virtual functions just don't exists and so it shouldn't
>call them at run time.

Why would you want to derive a class which omitted base-class functionality?
You wouldn't have an "is-a" relationship, and so you should probably not
be using inheritance; at least, not public inheritance.  It is time to
review the design if you find yourself wanting to do such a thing.

For private usage of the ABC, presumably just for code re-use, you could
supply dummy functions consisting of "assert(0)". This seems an
unusual-enough thing that direct language support would not be necessary.
--
Steve Clamage, stephen.clamage@eng.sun.com