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] [ > [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 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] [ >> [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 >> > >> > >
