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.

My statement that it offers more hope is contingent upon a mechanism
to update symbols, ifthis existed it would really offer the best
ofboth worlds.

As Ted has already pointed out in addition the java world has already
walked away from dynamic proxies for the most part.

In reply to Ted:

"Frankly, the argument of performance is moot--in the JVM, virtual method
dispatch can be optimized away in scenarios where the JVM realizes that
there is only one subtype of a given class loaded (thereby eliminating the
ambiguity around what the actual derived type is). The CLR could certainly
offer the same kinds of optimizations if it desired."

I agree with this although a new table would need to be kept matching
JIT'ed methods to ther dependencies as later an additional derived
type could be loaded (or created dynamically) at which point the
JIT'ed code for the original method would need to be pitched. This is
not rocket science but would also ot be a few hours worth of work :)
Anyone for a SSCLI project? :)

Cheers,

Greg

On 2/26/07, Frans Bouma <[EMAIL PROTECTED]> wrote:
> 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(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 DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to