Thursday, March 31, 2005
« Save IDL! | Main | Teaser »

Cross-pollination is one of the benefits of regular interaction with fellow speakers and authors. For instance, Juval Lowy was just showing me this cool and rather obscure feature where you can just make method calls “disappear”. Now I am not convinced that this is a good thing, as the effect is not at all explicit or obvious – but it is cool nonetheless.

 

The idea is that you can write a method:

 

Public Sub Foo()

End Sub

 

Then you can call this method elsewhere in your code. Perhaps even many places in your code:

 

Public Sub Client()

  Foo()

End Sub

 

So far so good. But now apply this attribute to the Foo method:

 

<Conditional("MyFlag")> _

Public Sub Foo()

End Sub

 

When you now compile your project, Foo is compiled, but the call to Foo in the Client method is not included in the result. Yes, that’s right – all calls to Foo everywhere in your code disappear without a trace. They aren’t in the CIL, and thus are just poof, gone.

 

To get those calls to Foo back, you need to define a compiler symbol:

 

#Const MyFlag = True

 

Now mystically, the calls to Foo will reappear in the compiled code.

 

This is a form of conditional compilation, similar to checking for a debug condition or something. But it is not explicit, and the caller will have no idea that they aren’t calling the method any more. Nor will the developer, since there’s no way for the caller to even know that the method is marked for disappearance.

 

Seems like a feature that should remain obscure, but from a purely geeky perspective it is pretty interesting.


Friday, April 01, 2005 12:30:17 AM (Central Standard Time, UTC-06:00)
Hey Rocky, I am actually using that - http://www.codebetter.com/blogs/sahil.malik/archive/2005/03/31/60954.aspx

Everything has a use I guess :)
Friday, April 01, 2005 7:44:32 AM (Central Standard Time, UTC-06:00)
That sounds useful for implementing an Assert method. Of course, the framework already *has* assertions, but it would still be useful for assertion-like constructs (Design by Contract, for example).

You're right, though, that you wouldn't want to use it in regular business logic.
Friday, April 01, 2005 2:43:03 PM (Central Standard Time, UTC-06:00)
AOP (aspect orient programming) is the opposite, has two "extras":

(1) You do not even need the "attributes": tell the compiler what class/method calls you want to remove, then, the compiler will do it.
(2) Not just removing, also adding: tell the compiler the pointcut (crosspoint), then, you can add "before", "after", or "around".

Of course, because JIT time thing, anything compiler-time can be load time! (from user point of view, it is run time!)


Kai
Friday, April 01, 2005 2:48:14 PM (Central Standard Time, UTC-06:00)
log4net is the way to go. But AOP is even better.
By "opposite", I mean "adding", instead of "removing".
Kai
Thursday, April 14, 2005 9:18:48 AM (Central Standard Time, UTC-06:00)
That's how System.Diagnostics.Debug.Write() works surely?
Josh Twist
Thursday, April 28, 2005 3:15:28 AM (Central Standard Time, UTC-06:00)
Furthermore, the neat thing is that the entire calling code is 'removed'

So, if you have System.Diagnostics.Debug.Write(s1 + s2 + s3 + s4), then all that nasty string concat doesn't take place in your RELEASE version!

:)
Josh Twist
Comments are closed.