> Remember that Andres is the reason we have non virtual by default.
> He is extremely conservative.
yeah. He is firmly against everything that even remotely looks like
aop-ish constructs, like weaving etc.. But as he doesn't control the CLR, it
might happen, though as he's a strong force inside MS devdiv, I don't see
them embrace this kind of stuff anytime soon.
Another thing which might solve it is a class loader system like
Java has so you can modify the IL at load time. This has other problems
(signing of assemblies, security issues) but these can be overcome IMHO. MS
didn't like it that much (but weren't negative as anders is about aop), but
maybe my proposal was badly worded, not sure. If Compiler as a service
doesn't work out, maybe we could push this route :)
FB
>
>
> On Tue, Sep 21, 2010 at 11:17 PM, Wenig, Stefan <[email protected]>
> wrote:
>
>
> compiler as a service would do that on a whole different level, I
> would not think that any existing code could be leveraged to use that...
>
>
>
> the CLR is not as far from that point as one would think. it would
> just need to put everything in vtables and put some rules into place for
> runtime subclassing/overriding. you'd pay for that in terms of an
additional
> level of indirection for members that are now non-virtual, but that could
be
> an option (per app domain, per assembly, what have you).
>
>
>
> or it could be implemented by compilers. just tell the compiler to
> make everything virtual internally, but control compile-time overriding
via
> attributes. done.
>
>
>
> I know it's never quite as easy, but that's not the problem. They
> just refuse to think about it because they have other plans, and they
don't
> see a reason to fix the problem now.
>
>
>
> ________________________________
>
> From: [email protected] [nhibernate-
> [email protected]] on behalf of Ayende Rahien
[[email protected]]
> Sent: Tuesday, September 21, 2010 23:11
>
> To: [email protected]
>
> Subject: Re: [nhibernate-development] Re: Proxy with lazy fields
does
> not implement INHibernateProxy
>
>
> Actually, compiler as a service is supposed to be able to allow
this.
> But, to be fair to Andres, you literally can't do this. You would
> have to re-write the CLR in order to allow this.
>
>
> On Tue, Sep 21, 2010 at 11:05 PM, Wenig, Stefan
> <[email protected]> wrote:
>
>
> you can intercept private member access using in-process
> remoting. it just requires some native code ;-) (at least it worked in
.net
> 1.0, I'd have to find the code in some old VSS(!) repository...)
>
> jokes aside, I once talked to anders hejlsberg at the
lang.net
> <http://lang.net> symposium.
> i proposed to make it possible to override non-virtual
members
> (private is not the problem in the CLR, these are orthogonal concepts
there)
> for subclass proxies that are generated at run time.
> the reasoning being that, like in reflection, you don't
> introduce a dependency if you discover the target at run time, same thing
as
> in reflection (e.g. serializing all private fields).
> also, unlike IL weaving or a boo-like C#5, this could be
used
> by existing frameworks like castle.
>
> anders' answer was basically "interesting. so you want to be
> able to change the behaviour of anything?" - and off he was.
>
> long story short: unlikely ;-)
>
> ________________________________________
> From: [email protected] [nhibernate-
> [email protected]] on behalf of Frans Bouma [[email protected]]
> Sent: Tuesday, September 21, 2010 18:36
> To: [email protected]
> Subject: RE: [nhibernate-development] Re: Proxy with lazy
> fields does not implement INHibernateProxy
>
>
> > That is the cost to pay for a very cool feature in .NET
(so
> far).
> > Before see the ISet, inside the framework, we had to wait
> the needs of EF4
> > (around 9 years).
> > To have Proxy support inside the .NET perhaps we have to
> wait others one
> or
> > two years.
> > To have static-proxy directly supported by the compiler
(to
> efficiently
> > intercept the access to a private field) perhaps in others
4
> or 5 years...
> > if we all don't create enough noise to speed up the change
a
> little bit.
>
> I fear that will never happen. What should happen is
IL
> weaving
> inside the CLR. Unfortunately, powerful forces inside MS
> either hate AOP
> like stuff to death or think it can be outsourced to the DLR
> (is that still
> alive?)
>
> But never is a big word, for what I know the CLR team
> moves
> incredibly slow so I wouldn't hold my breath
>
> FB
>
> >
> >
> > On Tue, Sep 21, 2010 at 1:02 PM, Ayende Rahien
> <[email protected]> wrote:
> >
> >
> > That is pretty much the point.
> > There isn't an unproxy stage for an entity with lazy
> fields.
> >
> > To give you an example: User.Image is lazy
> >
> > var user = session.Load<User>(1); // user is a proxy
> > NHibernateUtil.Initialize(user); // select id,name
> from user where
> id
> > = 1
> > var unproxiedUser =
> ((INHibernateProxy)user).GetImplementation();
> >
> > unproxiedUser is also proxy, because it need to
> intercept the
> > get_Image call
> >
> > On Tue, Sep 21, 2010 at 5:43 PM, Allan Ritchie
> > <[email protected]> wrote:
> >
> >
> > The problem is more widespread then just the
> LINQ provider.
> > You can't
> > unproxy the entity even at later stages
> outside of the LINQ
> > provider.
> >
> >
> > On Sep 21, 9:18 am, pvginkel
> <[email protected]> wrote:
> > > I would be very surprised if this really
> would be a bug,
> > because this
> > > would make the Linq provider unusable when
> enabling lazy
> > properties.
> > > Feedback is very welcome.
> > >
> > > On Sep 21, 2:36 pm, Allan Ritchie
> <[email protected]>
> > wrote:
> > >
> > > > I filed this as a bug. It was claimed
not
> to be a bug
> > which is fine,
> > > > but contrib packages like nhibernate
> validator seem to
> > fail against
> > > > lazy property proxies because of this
> exact issue. Can
> > anyone say
> > > > what the workaround is for this
situation?
> > >
> > > > On Sep 20, 7:33 am, pvginkel
> <[email protected]> wrote:
> > >
> > > > > I have a Linq query which takes an
> entity as
> parameter.
> > This entity
> > > > > itself is a proxy loaded with another
> Linq query and
> has
> > lazy
> > > > > properties. In "ReflectHelper.cs(267):
> Assembly
> assembly
> > =
> > > > > Assembly.Load(name.Assembly);" I get
an
> > FileNotFoundException because
> > > > > it tries to load the assembly of the
> proxy class. It
> > looks like the
> > > > > problem is that
> > NHibernateProxyHelper.GetClassWithoutInitializingProxy
> > > > > can't determine the type of the entity
> because the
> proxy
> > does not
> > > > > implement INHibernateProxy, so it
> returns the type of
> > the proxy.
> > >
> > > > > Is this something I can solve in my
> configuration, or
> is
> > something
> > > > > else going on here?
> > >
> > > > > I am using a nightly build of the NH3
> trunk.
> >
> >
> >
> >
> >
> >
> > --
> > Fabio Maulo
> >
>
>
