> 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
