On 2014-02-25 01:08:47 +0000, Tofu Ninja said:

> On Tuesday, 25 February 2014 at 00:55:55 UTC, Tofu Ninja wrote:
>> Also, in some cases it is not enough just to ensure that it is called, some times you will want to make sure that it is called at the beginning or end of the function. Though this is harder to get right, not really sure how it would work with returns.
> 
> In the case where it would be needed to be called at the beginning or the end of the new method. The compiler might be able to implicitly add it in itself, similar to how super(); is implicitly added to the beginning of overridden constructors.

So far as I'm understanding this thread,  Steve Teale is asking for a way to inject code before and after a call to a function from other places in the program.   E.g. Write some function foo, write some function bar, and specify that any time foo is called, bar should be called immediately after *automagically*.

The reason this hasn't been done in any language I'm aware of is because you can solve the same problem using existing polymorphism, and it's a horribly awful design practice to have hidden code like that.


-S.

On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:

> extend void foo()   // Declared in base class as cumulative void foo()
> {
>    super.foo();  // Compiler does this for you
>                                   // similar to changing a light bulb ;=)
>
>    // the extra stuff
> }

When I've had a need for base classes to call super class functions, I certainly wanted a way to enforce it. I just don't know if it would just lead to other OOP design problems.

"qznc" <qznc@web.de> writes:

> Sounds a little like the :after mechanism of the Common Lisp Object System (CLOS). They also have :before, if your extra code should run before the super-call. The third variant is :around, which is like the default overwriting in D et. al.

Yes! - and CLOS came from my all time favorite playland, the Symbolics Lisp Machine with its version of OOP called Flavors.

See page 25 section 1.12 Method Combination and you will see a zoo of ways to combine methods from a class ineritance hierarchy.

ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-602.pdf

A fun read.  I wonder what David Moon is doing today?
-- 
Dan

On Tuesday, 25 February 2014 at 03:13:23 UTC, Shammah Chancellor wrote:
> So far as I'm understanding this thread,  Steve Teale is asking for a way to inject code before and after a call to a function from other places in the program.   E.g. Write some function foo, write some function bar, and specify that any time foo is called, bar should be called immediately after *automagically*.
>
> The reason this hasn't been done in any language I'm aware of is because you can solve the same problem using existing polymorphism, and it's a horribly awful design practice to have hidden code like that.
>
>
It's a bit more specific than 'from other places in the program', and anyway, once you've accepted virtual functions, you've accepted 'automagic' ;=)

I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through.

Steve

On 2014-02-25 10:23:31 +0000, Steve Teale said:

> On Tuesday, 25 February 2014 at 03:13:23 UTC, Shammah Chancellor wrote:
>> So far as I'm understanding this thread,  Steve Teale is asking for a way to inject code before and after a call to a function from other places in the program.   E.g. Write some function foo, write some function bar, and specify that any time foo is called, bar should be called immediately after *automagically*.
>> 
>> The reason this hasn't been done in any language I'm aware of is because you can solve the same problem using existing polymorphism, and it's a horribly awful design practice to have hidden code like that.
>> 
>> 
> It's a bit more specific than 'from other places in the program', and anyway, once you've accepted virtual functions, you've accepted 'automagic' ;=)
> 
> I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through.
> 
> Steve

If I was understanding properly, you were suggesting that the code should be executed even for instances of the base class.    There's some automagic that's good, that sounds like a vile thing to have to debug when you take over for somebody else.

-S.

On Tuesday, 25 February 2014 at 10:23:32 UTC, Steve Teale wrote:
> I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through.
>
OK, it's at britseyeview.com/cumulative.txt.

I think enforcement of the call to super.handleCommand() would get most of the way down the road. More could be done if the compiler inserted the super call, and maintained an implicit class member equivalent to my 'cmdResult' that could be tested in override implementations of handleCommand(). But I think that is OTT.

Steve

On 2014-02-25 11:04:23 +0000, Steve Teale said:

> OK, it's at britseyeview.com/cumulative.txt.
> 
> I think enforcement of the call to super.handleCommand() would get most of the way down the road. More could be done if the compiler inserted the super call, and maintained an implicit class member equivalent to my 'cmdResult' that could be tested in override implementations of handleCommand(). But I think that is OTT.
> 
> Steve

It seems we were talking about different things.   I thought you were suggesting the following:

void main()
{
  auto a = new Base();
  int[] a1 = [ 0, 1, 2, 3 ];
  foreach (int n; a1)
     a.dealWithCommand(n); <-- Calls all the extension methods.
}

On 2014-02-25 05:38:15 +0000, Jesse Phillips said:

> When I've had a need for base classes to call super class functions, I certainly wanted a way to enforce it. I just don't know if it would just lead to other OOP design problems.

Sounds like a good reason to use unittests to me.   The compiler can't possibly deal with all the different ways you might want to enforce an OOP pattern in a particular program.   Introducing more keywords does not seem like a fix.

-S.

On Tuesday, 25 February 2014 at 11:13:44 UTC, Shammah Chancellor wrote:
> On 2014-02-25 05:38:15 +0000, Jesse Phillips said:
>
>> When I've had a need for base classes to call super class functions, I certainly wanted a way to enforce it. I just don't know if it would just lead to other OOP design problems.
>
> Sounds like a good reason to use unittests to me.   The compiler can't possibly deal with all the different ways you might want to enforce an OOP pattern in a particular program.   Introducing more keywords does not seem like a fix.
>
> -S.

As unit tests are optional, they are in no way an enforcement. And for library writers(which is who this idea is mainly for I think), writing unit tests to try and test user written code seems a little unreasonable, especially as they don't have access to the code :/

On Tuesday, 25 February 2014 at 11:04:24 UTC, Steve Teale wrote:
> On Tuesday, 25 February 2014 at 10:23:32 UTC, Steve Teale wrote:
>> I'm writing a little example program that illustrates what I'm getting at, and I'll post it somewhere when I'm through.
>>
> OK, it's at britseyeview.com/cumulative.txt.

However, I now realize you can do better in D. The base class needs to define an array of delegates. It appends its handler to the array, then derived classes each append their handler. The append is done like:

handlers ~= &Red.handleCommand;

Am I right in thinking that this makes the calls non-virtual?  Anyway, the result is I think exactly what I wanted.

The example is at britseyeview.com/cum2.txt.

Steve