www.digitalmars.com         C & C++   DMDScript  

D - "progressive" methods

reply "Craig Black" <cblack ara.com> writes:
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
Jul 01 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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

 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

 overloaded method.  These parameters are automatically passed into the

 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

 --Craig

Jul 01 2002
parent reply "Craig Black" <cblack ara.com> writes:
 That sounds cool;  However in your example B doesn't inherit from A.

 it have?

Oops, yes.
 One problem is that you have no control over when the superclass method

 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

  *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

 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. :)
Jul 01 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
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.
Jul 01 2002
parent reply "Craig Black" <cblack ara.com> writes:
 You could allow the overloaded method to explicitly call the base


 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
Jul 01 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
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


 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

 cases.  Fundamentally we are dealing with the same principle as with
 information hiding.  We are trying to prevent a derived class from

 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

Jul 02 2002
parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
"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

 member that makes the call (yuck).

 I'd go even further to suggest if that progression could be turned off

 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


 If no explicit call exists, then the compiler would insert a the




 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

 cases.  Fundamentally we are dealing with the same principle as with
 information hiding.  We are trying to prevent a derived class from

 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


 traditional OOP (or a turing machine) but I like the "progressive" and
 "digressive" syntax better.

 Craig


Jul 05 2002
parent "anderson" <anderson firestar.com.au> writes:
"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

 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


 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


 the returned values or only make progressive work with void's.

We allow covariant return types, as in C++. Works perfectly well, and

 sense to all clients of the hierarchies classes

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


Jul 05 2002
prev sibling parent "Matthew Wilson" <matthew thedjournal.com> writes:
"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


 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

 cases.  Fundamentally we are dealing with the same principle as with
 information hiding.  We are trying to prevent a derived class from

 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

Jul 05 2002