> Sure, and I understand his reasons and agree with them. That reasoning
does
> not extend to runtime-discovery and subclass proxy generation though.
>
> This is just something they've never really considered, and with C#5 in
the
> making it's very unlikely they ever will. For whatever reasons.
>
> I think it's just unbelievable how little the CLR and C# teams take the
> needs of frameworks into account. They are complicating their own stuff,
> like Policy Injection (a term probably coined to get AOP past Anders
> unnoticed ;-)) or Code Contracts. But hey, if some designer-happy VS guy
> wants partial methods, they get it. A nod from the Office team? New COM
> interop in C# 4(!).
good points.
I've posted an email on the C# insiders mailinglist (the C# team
reads /posts there) asking whether they want to consider IL weaving/class
loaders for C# / .NET vNext. Not sure if it will be successful, but we can
always try ;)
FB
> </rant>
>
>
>
> From: [email protected] [mailto:nhibernate-
> [email protected]] On Behalf Of Ayende Rahien
> Sent: Tuesday, September 21, 2010 11:37 PM
> To: [email protected]
> Subject: Re: [nhibernate-development] Re: Proxy with lazy fields does not
> implement INHibernateProxy
>
>
>
> Remember that Andres is the reason we have non virtual by default.
>
> He is extremely conservative.
>
> 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] <mailto:nhibernate-
> [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
> >
>
>
>
>
