> A dynamic proxy at runtim is certainly not the "preferred way" of > weaving aspects in *ANY* language tht has an intermediate > representation. A "link" time weave would be preferred for many > reasons. The link time weave also helps greatly in mitigating common > issues such as "too much magic".
I don't see how compile/link time weaving isn't too much magic, the code IS mangled. > Although has been decided to be a > non-optimal way of doing things, using the profiling API to > uinstrument IL at runtime holds much more possibility of being a good > system than the dynamic proxy. You have to elaborate on this, as the profiler api has disadvantages as well. FB > > Cheers, > > Greg > > On 2/25/07, Frans Bouma <[EMAIL PROTECTED]> wrote: > > > On the IL level there are various call* instructions like call, callvirt > and > > > calli. The former two are the ones which interest us most in this > > > discussion. As you probably know, a virtual call has a level of > indirection > > > through a so-called v-table structure ("method table"), which makes such a > > > call more expensive. If you need more information on this, drop a follow- > up > > > mail or browse the internet or the CLI spec. > > > > > > As Tony pointed out, Anders Hejlsberg has pointed out the reasons for the > > > choice of non-virtual by default on > > > http://www.artima.com/intv/nonvirtual.html. Performance and versioning are > > > the main reasons as pointed out by Anders. > > > > Still, it's sad this decision was made, because AOP is a tad more > > difficult because subclassing at runtime to create dyn. proxies now relies > on > > the developer to make things virtual, while in Java for example, everything > is > > virtual by default, so it's more natural: the developer can just write code > > and it's weavable at runtime. > > > > dyn. proxy at runtime has many advantages, and because MS doesn't > > realize that a dyn. proxy mechanism is really needed in the CLR, all kinds > of > > tricks have to be used which aren't really transparent. This IMHO limits > .NET > > when compared to Java. > > > > FB > > > > ------------------------------------------------------------------------ > > Lead developer of LLBLGen Pro, the productive O/R mapper for .NET > > LLBLGen Pro website: http://www.llblgen.com > > My .NET blog: http://weblogs.asp.net/fbouma > > Microsoft MVP (C#) > > ------------------------------------------------------------------------ > > > > > > > > > > -Bart > > > > > > -----Original Message----- > > > From: Discussion of advanced .NET topics. > > > [mailto:[EMAIL PROTECTED] On Behalf Of Tony Nassar > > > Sent: zondag 25 februari 2007 4:26 > > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > > Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was Implementing > an > > > Interface - C# vs. VB.NET > > > > > > Assuming your question isn't simply rhetorical, the reason is very simple: > > > the CLS didn't make it its business to force *every* language to be like > > > Java in this respect. Anders Hjellberg has explained exactly why C# is > this > > > way; check out the interviews with him at artima.com. > > > > > > > Anybody know why methods aren't virtual by default in .NET? > > > > It seems like a really bad default to have all methods non-virtual. > > > > > > =================================== > > > This list is hosted by DevelopMentor. http://www.develop.com > > > > > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentor. http://www.develop.com > > > > > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at http://discuss.develop.com > > > > > -- > Studying for the Turing test > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com