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] [[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]<mailto:[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]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Frans Bouma [[email protected]<mailto:[email protected]>] Sent: Tuesday, September 21, 2010 18:36 To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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 >
