Okay, since this months-old thread has now turned towards AOP, I'll chime in, since I've been working on a proxy-based AOP tool (and its uses) for the last two years.
As I said the profiling API is not an optimal way of doing things (in particulaer because there is no good way of updating symbols on the fly). Doing a byte coe weave (link time) one can quite easily update symbols for ven code.
The profiling API is indeed suboptimal, because, as you say, you can't really update symbols on the fly. In addition, - Aspect-oriented applications relying on the profiling API can't be investigated with a "real" profiler, - Enabling the profiling hooks slows down an application quite a bit, and - The profiling API's functionality for replacing method bodies (which is needed for well-performing and powerful dynamic AOP) has allegedly been disabled in 2.0 (there's now Edit & Continue, but, well, that's not for a production environment either) [1]. Runtime-generated subclass proxies are a good choice for AOP (or similar techniques for advanced separation of concerns) in many scenarios, because they - Are very flexible (the weaving rules can change at runtime), - Allow good debugging (symbols can be generated together with the proxy), - Have good adoptability potential (they only use well-known concepts, there is no mangling), and - Have good performance (once the weaving is done).
As Ted has already pointed out in addition the java world has already walked away from dynamic proxies for the most part.
That's not really true. AspectJ, which Ted used as an example, hasn't walked away, it has been a compiler from the beginning (a possibility of doing post-compilation weaving was added some time ago). But AspectJ is a full aspect-oriented programming language and _the_ reference tool. Of course, it uses bytecode mangling, since this provides the best performance and AOP feature set. Dynamic proxies are also used in the Java world. IIRC, JBoss uses dynamic proxies, Spring uses dynamic proxies, Hibernate uses dynamic proxies (okay, that's not really AOP). Dynamic proxies do have their advantages, it's just that their feature set will always be constrained by the mechanisms provided by the platform. And .NET doesn't provide that much. What regards the original discussion - I think the reasons why C# methods aren't virtual by default have been thoroughly discussed in July last year. The argument I like most is that of contract and semantics. I quote Barry Kelly from this thread: "Virtual methods are quite difficult to design properly. They require two, independent, sets of semantics: one for callers and another for implementers. Designing a class to be robust and secure in the face of malicious or naive overriding - something which essentially introduces external code in the middle of the class's implementation - is not trivial. Inheritance is probably the closest coupling that can be created between two classes, and we all know why coupling is bad when designing robust, modular systems. Virtual methods make coupling even closer, because one class replaces methods in the other. It's harder to change the implementation of a class which has lots of virtual methods, because descendants are more closely coupled to the ancestor. That's where the maintenance and versioning problems come in." Regards, Fabian [1] http://mice.cs.columbia.edu/getTechreport.php?techreportID=438 =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
