Comments on Entropy Overload: Virtual method interception

Really impressive! Is this a way to make APO (aspe...

2010-09-09T17:18:38.056+01:00

Really impressive! Is this a way to make APO (aspect oriented programing) in Delphi?

It's a very powerfull feature, and I'm hap...

2010-09-09T13:40:16.031+01:00

It's a very powerfull feature, and I'm happy to see it implemented in Delphi.

BWT, for those who are using D2010, I've managed to implement something very similar to this to support mocking and other features on Emballo: http://code.google.com/p/emballo

It's a work in progress, but it's already working.

Unfortunately, being able to mock only virtual methods isn't very helpfull. My goal is to make the interception possible for non virutal methods by using code overwriting, the same way people use to do dll hooking.

I got to look at something like spring.net, castle...

2010-09-07T16:46:50.742+01:00

I got to look at something like spring.net, castle.net etc. Even more interesting thing is PostSharp.

Sure, it is easy to implement QueryInterface yours...

2010-09-07T12:35:41.345+01:00

Sure, it is easy to implement QueryInterface yourself and thus decide which casts you allow. However, you also have to manufacture an interface pointer to return so the caller can invoke the interface's methods. This involves dynamic generation of a vtable similar to what TVirtualMethodInterceptor does today.

Apollonius - it's true, .NET remoting is more ...

2010-09-06T21:22:48.352+01:00

Apollonius - it's true, .NET remoting is more powerful, and I agree, instrumenting every method call, including statics, and every field access, including field-backed properties (as Leonardo suggests) would be a step too far, because the compiler would have no way ahead of time knowing which classes would be modified at runtime, and would therefore make every access slower. So it is only for explicitly labeled virtual methods for now. I could envision however an "instrumentable" class, specifically labeled as such, whereupon every property access and every non-virtual method gains "virtual-like" behaviour, not in the language, but in the runtime, with sufficient indirection to approach the power of .NET's remoting.

As to dynamically implementing interfaces, technically, much of that is possible today, so long as QueryInterface is in the call chain when the dynamic cast occurs. That's not always the case, of course.

Adding interface implementations should already be...

2010-09-06T21:22:42.274+01:00

Adding interface implementations should already be possible by intercepting the virtual method QueryInterface.

To Anonymous decrying the high-concept thing: I...

2010-09-06T21:17:09.966+01:00

To Anonymous decrying the high-concept thing: I'd look at this feature as a piece of infrastructure, like I said, that third party libraries (that may be oriented towards testing or remoting etc.) may use. Its usefulness for the average developer may not be high, but the usefulness of the things you can build with it would, I believe, be much higher.

Definitely interesting. .NET Remoting is much more...

2010-09-06T20:49:30.538+01:00

Definitely interesting. .NET Remoting is much more powerful - it allows interception of nonvirtual methods and even field accesses - but requires inheritance from MarshalByRefObject. Although this is nice to have, I would not advocate it for an unmanaged language like Delphi. It would require cooperation from the compiler and cause a runtime overhead even for accesses of non-proxy objects, so it is not worth the disadvantages in my opinion.

The next step would be the possibility to implement additional interfaces which are not implemented by the original class. It would be even cooler if this could be done on demand like in .NET where you can implement IRemotingTypeInfo and thus decide if you implement an interface just when the cast occurs.

Lovely!

2010-09-06T20:44:39.735+01:00

Lovely!

Barry, as always: you have very interesting conce...

2010-09-06T20:41:51.993+01:00

Barry,

as always: you have very interesting concepts and ideas. But, which "normal" coder can cope with such high sophisticated language constructs? I like the "keep it simple and stupid". 2-5%??? It is not worth your effort.

Very interesting Barry, as usual. It would be nice...

2010-09-06T19:54:36.696+01:00

Very interesting Barry, as usual. It would be nice also to have Property interceptors in a future version, not just properties that have getters and/or setters, but properties of the type "property myProp: string read FProp write FProp" (that write directly to variables).

Why this could be important to me?, imagine an RTTI based ORM, that assign just a couple of values to an object that has, say 10 properties, then call the method "save" to store the object in a databse. With "property interceptors" the programmer could know at runtime wich properties were changed, then automatically create an sql update command with just those properties.