Hey guys,

I have an idea for a new kind of member method that I have coined a "progressive" method.  (Perhaps the there is already a term for this that I am not aware of.)

Here's an example:

class A
{
  public:
     progressive void foo() { printf("\nA foo()"); }
};

class B
{
  public:
     progressive void foo() { printf("\nB foo()"); }
};

int main(...)
{
   B b;
   b.foo();
   return 0;
}

Output:

A foo
B foo

If the progressive method has parameters, the parameters must match in each overloaded method.  These parameters are automatically passed into the next method in the progression.

You could also have "digressive" methods that would be called in reverse order.

This type of method has many applications in object-oriented programming. It's intersting to note that C++ constructors and destructors work this way.

--Craig

That sounds cool;  However in your example B doesn't inherit from A.  Should it have?

One problem is that you have no control over when the superclass method gets called.  By your example it gets called at the start of the function.  For ctors that may be fine, but for dtors you'd want it the other way.  And for certain other kinds of methods you'd want to insert code both before *and* after the superclass call.

Also the signature won't necessarily stay the same;  I suppose progressive would only work if the signature stayed the same.  Essentially an automated method chain.

D has this nifty super keyword that makes calling the superclass easy.  Do we really need anything more?

Sean

"Craig Black" <cblack@ara.com> wrote in message news:afq2mj$2rnq$1@digitaldaemon.com...
> Hey guys,
>
> I have an idea for a new kind of member method that I have coined a "progressive" method.  (Perhaps the there is already a term for this that
I
> am not aware of.)
>
> Here's an example:
>
> class A
> {
>   public:
>      progressive void foo() { printf("\nA foo()"); }
> };
>
> class B
> {
>   public:
>      progressive void foo() { printf("\nB foo()"); }
> };
>
> int main(...)
> {
>    B b;
>    b.foo();
>    return 0;
> }
>
> Output:
>
> A foo
> B foo
>
> If the progressive method has parameters, the parameters must match in
each
> overloaded method.  These parameters are automatically passed into the
next
> method in the progression.
>
> You could also have "digressive" methods that would be called in reverse order.
>
> This type of method has many applications in object-oriented programming. It's intersting to note that C++ constructors and destructors work this
way.
>
> --Craig

> That sounds cool;  However in your example B doesn't inherit from A.
Should
> it have?

Oops, yes.

> One problem is that you have no control over when the superclass method
gets
> called.  By your example it gets called at the start of the function.  For ctors that may be fine, but for dtors you'd want it the other way.

That's why I proposed "progressive" and "digressive" methods.

> And for certain other kinds of methods you'd want to insert code both
before
>  *and* after the superclass call.

You could allow the overloaded method to explicitly call the base method. If no explicit call exists, then the compiler would insert a the call implicitly.

> Also the signature won't necessarily stay the same;  I suppose progressive would only work if the signature stayed the same.  Essentially an
automated
> method chain.

Perhaps you could add additional parameters to overloaded methods.  The first parameter(s) would have to be the same as the super class.

> D has this nifty super keyword that makes calling the superclass easy.  Do we really need anything more?

Nope.  All you really need is a turing machine. :)

On Mon, 1 Jul 2002 13:24:16 -0500 "Craig Black" <cblack@ara.com> wrote:

> You could allow the overloaded method to explicitly call the base method. If no explicit call exists, then the compiler would insert a the call implicitly.

Sometimes, you don't want the call to happen at all...

I think it's better to get stick with "super". It gives programmer full control over what he does. After all, "progressive" would be absolutely equivalent to adding a super-call at the beginning of function.

> > You could allow the overloaded method to explicitly call the base
method.
> > If no explicit call exists, then the compiler would insert a the call implicitly.
>
> Sometimes, you don't want the call to happen at all...

If this is the case, then don't use the progressive keyword.  It's not mandatory.

> I think it's better to get stick with "super". It gives programmer full control over what he does. After all, "progressive" would be absolutely equivalent to adding a super-call at the beginning of function.

The programmer does not lose any control.  It gives the superclass more control as to how methods can be overloaded, which is what you want in some cases.  Fundamentally we are dealing with the same principle as with information hiding.  We are trying to prevent a derived class from misusing the superclass methods.

This idea has arisen because I have run into a number of cases where I wanted to ensure that the base method was called and then the derived method.  I didn't want someone else to carelessly overload a method and forget to call the base method.  There are workarounds for this case using traditional OOP (or a turing machine) but I like the "progressive" and "digressive" syntax better.

Craig

I agree, a progressive member in a class could be useful. Often I find in C++ that I have to keep documenting to the users, to call super member before (after) all other calls. The alternative is to have a virtual private member that makes the call (yuck).

I'd go even further to suggest if that progression could be turned off later down the track.

class A
{
  public:
     progressive void foo() { printf("\nA foo()"); }
};

class B
{
  public:
     void foo() { printf("\nB foo()"); }
};


Java did something like this for progression. But I forget exactly how it was able to enforce the rules.

It'd also be useful if applied to static and constuctors (when neede).

One problem to deal with is members that have a return type. Do we ignore the returned values or only make progressive work with void's.

Progression would simply make the language more strongly typed.

"Craig Black" <cblack@ara.com> wrote in message news:afqc1d$5ev$1@digitaldaemon.com...
> > > You could allow the overloaded method to explicitly call the base
> method.
> > > If no explicit call exists, then the compiler would insert a the call implicitly.
> >
> > Sometimes, you don't want the call to happen at all...
>
> If this is the case, then don't use the progressive keyword.  It's not mandatory.
>
> > I think it's better to get stick with "super". It gives programmer full control over what he does. After all, "progressive" would be absolutely equivalent to adding a super-call at the beginning of function.
>
> The programmer does not lose any control.  It gives the superclass more control as to how methods can be overloaded, which is what you want in
some
> cases.  Fundamentally we are dealing with the same principle as with information hiding.  We are trying to prevent a derived class from
misusing
> the superclass methods.
>
> This idea has arisen because I have run into a number of cases where I wanted to ensure that the base method was called and then the derived method.  I didn't want someone else to carelessly overload a method and forget to call the base method.  There are workarounds for this case using traditional OOP (or a turing machine) but I like the "progressive" and "digressive" syntax better.
>
> Craig
>
>

"It gives the superclass more control as to how methods can be overloaded, which is what you want in some cases"

Spot on! One of the drawbacks of implementation inheritance is that the author of the base class has little control over the derived, which progressive and *regressive* (this is the converse to progressive, I digress) methods would provide.

Implementation inheritance sucks in many ways, but this may be one way to help in untangling the undergrowth. Let's have them


"Craig Black" <cblack@ara.com> wrote in message news:afqc1d$5ev$1@digitaldaemon.com...
> > > You could allow the overloaded method to explicitly call the base
> method.
> > > If no explicit call exists, then the compiler would insert a the call implicitly.
> >
> > Sometimes, you don't want the call to happen at all...
>
> If this is the case, then don't use the progressive keyword.  It's not mandatory.
>
> > I think it's better to get stick with "super". It gives programmer full control over what he does. After all, "progressive" would be absolutely equivalent to adding a super-call at the beginning of function.
>
> The programmer does not lose any control.  It gives the superclass more control as to how methods can be overloaded, which is what you want in
some
> cases.  Fundamentally we are dealing with the same principle as with information hiding.  We are trying to prevent a derived class from
misusing
> the superclass methods.
>
> This idea has arisen because I have run into a number of cases where I wanted to ensure that the base method was called and then the derived method.  I didn't want someone else to carelessly overload a method and forget to call the base method.  There are workarounds for this case using traditional OOP (or a turing machine) but I like the "progressive" and "digressive" syntax better.
>
> Craig
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:afru49$1k02$1@digitaldaemon.com...
> I agree, a progressive member in a class could be useful. Often I find in C++ that I have to keep documenting to the users, to call super member before (after) all other calls. The alternative is to have a virtual
private
> member that makes the call (yuck).
>
> I'd go even further to suggest if that progression could be turned off
later
> down the track.

How could that be?

>
> class A
> {
>   public:
>      progressive void foo() { printf("\nA foo()"); }
> };
>
> class B
> {
>   public:
>      void foo() { printf("\nB foo()"); }
> };
>
>
> Java did something like this for progression. But I forget exactly how it was able to enforce the rules.
>
> It'd also be useful if applied to static and constuctors (when neede).

?? If you did it to constructors you'd be in masses of trouble. Don't get how you'd do it for statics either

>
> One problem to deal with is members that have a return type. Do we ignore the returned values or only make progressive work with void's.

We allow covariant return types, as in C++. Works perfectly well, and makes sense to all clients of the hierarchies classes

>
> Progression would simply make the language more strongly typed.
>
> "Craig Black" <cblack@ara.com> wrote in message news:afqc1d$5ev$1@digitaldaemon.com...
> > > > You could allow the overloaded method to explicitly call the base
> > method.
> > > > If no explicit call exists, then the compiler would insert a the
call
> > > > implicitly.
> > >
> > > Sometimes, you don't want the call to happen at all...
> >
> > If this is the case, then don't use the progressive keyword.  It's not mandatory.
> >
> > > I think it's better to get stick with "super". It gives programmer full control over what he does. After all, "progressive" would be absolutely equivalent to adding a super-call at the beginning of function.
> >
> > The programmer does not lose any control.  It gives the superclass more control as to how methods can be overloaded, which is what you want in
> some
> > cases.  Fundamentally we are dealing with the same principle as with information hiding.  We are trying to prevent a derived class from
> misusing
> > the superclass methods.
> >
> > This idea has arisen because I have run into a number of cases where I wanted to ensure that the base method was called and then the derived method.  I didn't want someone else to carelessly overload a method and forget to call the base method.  There are workarounds for this case
using
> > traditional OOP (or a turing machine) but I like the "progressive" and
> > "digressive" syntax better.
> >
> > Craig
> >
> >
>
>

"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:ag3hll$87e$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:afru49$1k02$1@digitaldaemon.com...
> > I'd go even further to suggest if that progression could be turned off
> later
> > down the track.
>
> How could that be?

I don't know how the syntax would look but I'd basicly go back to only calling the current virtual function.  Basicly enpowering the user to disable progression on a particlar method. But it'd have to be made hard to switch it off to encorage users not to do it often (leaving it to the hard core programmers who know what there doing). It's entirly possible from a compliers point of view, simply don't call the parent method.

> >
> > class A
> > {
> >   public:
> >      progressive void foo() { printf("\nA foo()"); }
> > };
> >
> > class B
> > {
> >   public:
> >      void foo() { printf("\nB foo()"); }
> > };
> >
> >
> > Java did something like this for progression. But I forget exactly how
it
> > was able to enforce the rules.
> >
> > It'd also be useful if applied to static and constuctors (when needed).
>
> Don't get how you'd do it for statics either

Only because D doesn't support static virtual members which it'd be useful for.  But I suppose you couldn't use it with statics in there current state.

> >
> > One problem to deal with is members that have a return type. Do we
ignore
> > the returned values or only make progressive work with void's.
>
> We allow covariant return types, as in C++. Works perfectly well, and
makes
> sense to all clients of the hierarchies classes

Fine.

> >
> > Progression would simply make the language more strongly typed.