internal is not required. if you have an internal, to be proxiable it need even protected.
-- Fabio Maulo El 24/05/2011, a las 21:32, Michael Teper <[email protected]> escribió: > Fabio, urgency is in the eye of the beholder, so that's neither here > nor there. Having the question in multiple places may not carry much > value, but having the answer be more discoverable, in my opinion, > would have value. > > Your comment, unfortunately, doesn't really directly answer the > question. Can you either explain (or, point me to an explanation) of > why the internal attribute is required in addition to the protected > attribute in order for proxying to work? That's really all I am > asking. Going from private to protected internal is a semantic change, > and I want to understand what it is that I am paying the price for. In > effect, this change in NH requires that we either accept that auto > properties can no longer be private, or not use auto properties at > all, which would be a shame as it's nice syntactic sugar. > > Thank you! > -Michael > > On May 24, 4:42 pm, Fabio Maulo <[email protected]> wrote: >> If you can proxy something that we can't please let us know. >> If you want you can disable, through configuration, the proxy >> validator... then when you have some default(T) instead the exepected >> value, please activate the proxy validator before file an new issue. >> Thanks. >> >> P.S. a question in SO, the same in twitter, a mail to dev-list.... >> wow! pretty URGENT matter. >> >> -- >> Fabio Maulo >> >> El 24/05/2011, a las 17:42, Michael Teper <[email protected]> escribió: >> >> >> >>> I posted a related question on SO: >>> http://stackoverflow.com/questions/6114869/why-does-nhibernate-requir.... >>> Is there something I am missing? Why is the "internal" attribute >>> called for? >> >>> Thank you! >>> -Michael >> >>> On May 5, 6:35 am, Fabio Maulo <[email protected]> wrote: >>>> btw the note about the breaking change is in the releasenotes.txt since the >>>> beginning. ;) >> >>>> -- >>>> Fabio Maulo >> >>>> El 04/05/2011, a las 17:18, Stephen Bohlen <[email protected]> escribió: >> >>>> You'll have to talk to Anders for that :) >> >>>> Steve Bohlen >>>> [email protected]http://blog.unhandled-exceptions.comhttp://twitter.com/sbohlen >> >>>> On Wed, May 4, 2011 at 4:16 PM, Fabio Maulo <[email protected]> wrote: >>>>> well... give me something to override private members on the fly (without >>>>> use IL rewrite) and I'll remove that restriction ;) >> >>>>> On Wed, May 4, 2011 at 5:01 PM, Stephen Bohlen <[email protected]> wrote: >> >>>>>> lol -- there is no doubt in my mind at all that our restrictions are >>>>>> almost guaranteed to be the least invasive of all of the options, but I'd >>>>>> *still* like to ensure that we try to measure ourselves by something more >>>>>> rigorous than "we're not as bad as MS" :D >> >>>>>> Steve Bohlen >>>>>> [email protected] >>>>>> http://blog.unhandled-exceptions.com >>>>>> http://twitter.com/sbohlen >> >>>>>> On Wed, May 4, 2011 at 3:56 PM, Diego Mijelshon >>>>>> <[email protected]>wrote: >> >>>>>>> Steve, do you know what the default behavior for EF "code-first" is when >>>>>>> a many-to-one property is not virtual? >>>>>>> It loads as null and lazy load doesn't work. >>>>>>> I'll take NH's fail-early, simple restrictions any time. >> >>>>>>> Diego >> >>>>>>> On Wed, May 4, 2011 at 11:12, Stephen Bohlen <[email protected]> wrote: >> >>>>>>>> That feels like (yet another) constraint on my object modeling dictated >>>>>>>> by my persistence choice (tail wags dog). There are already several of >>>>>>>> these w/NH adoption; I'd prefer not to introduce yet another one if we >>>>>>>> can >>>>>>>> avoid it. >> >>>>>>>> Steve Bohlen >>>>>>>> [email protected] >>>>>>>> http://blog.unhandled-exceptions.com >>>>>>>> http://twitter.com/sbohlen >> >>>>>>>> On Wed, May 4, 2011 at 10:08 AM, Ramon Smits >>>>>>>> <[email protected]>wrote: >> >>>>>>>>> Can't you just convert private to protected? >> >>>>>>>>> On Wed, May 4, 2011 at 4:05 PM, cremor <[email protected]> wrote: >> >>>>>>>>>> Oh, lazy properties, right. I didn't think about that because I've >>>>>>>>>> never used them. >> >>>>>>>>>> Is there a way to just disable that lazy property check? Because I >>>>>>>>>> don't want to disable the whole proxy checking for sure. >>>>>>>>>> If not, would it be possible to change that code so it does the check >>>>>>>>>> for private accessors only if the property is really mapped as lazy >>>>>>>>>> property? >> >>>>>>>>>> On May 4, 3:54 pm, Fabio Maulo <[email protected]> wrote: >>>>>>>>>>> yes if you don't want use lazy-properties. >>>>>>>>>>> You can disable the validator but then you have to know what will >>>>>>>>>> happen if >>>>>>>>>>> you use lazy-properties. >> >>>>>>>>>>> On Wed, May 4, 2011 at 10:39 AM, cremor <[email protected]> wrote: >>>>>>>>>>>> I just tried a build of the current trunk (coming from >>>>>>>>>> 3.2.0.Alpha2) >>>>>>>>>>>> and was quite surprised that nothing worked any more because >>>>>>>>>>>> NHibernate complained about many of my entities not being >>>>>>>>>> proxyable. >> >>>>>>>>>>>> Example property: >>>>>>>>>>>> public virtual SomeEntity SomeEntity { get; private set; } >> >>>>>>>>>>>> Seems like in r5718 the DynProxyTypeValidator was changed to also >>>>>>>>>>>> check non-public property accessors (line 57 from >>>>>>>>>>>> "property.GetAccessors(false)" to "property.GetAccessors(true)"). >>>>>>>>>> I >>>>>>>>>>>> see that it's needed to check protected/protected internal >>>>>>>>>> accessors >>>>>>>>>>>> (so the previous code wasn't checking everything), but shouldn't >>>>>>>>>>>> private accessors be allowed? >> >>>>>>>>>>> -- >>>>>>>>>>> Fabio Maulo >> >>>>>>>>> -- >>>>>>>>> Ramon >> >>>>> -- >>>>> Fabio Maulo- Hide quoted text - >> >>>> - Show quoted text -- Hide quoted text - >> >> - Show quoted text -
