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


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 "Craig Black" <cblack ara.com> writes:
 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. :)
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




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
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




 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
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


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
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


 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.
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




 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
Jul 05 2002