Fabio, you are right. I could have sworn I tested that, but facts are facts and I must eat crow. I must have misread the error message, but I checked it now and it's perfectly clear.
In any event, it's still really quite a shame that we are losing ability to have private setters that can be used safely in the constructor (see http://confluence.jetbrains.net/display/ReSharper/Virtual+method+call+in+constructor for consice explanation of why calling a protected setter in the constructor may be a bad idea). Thanks for setting me straight! -Michael On May 25, 5:04 am, Fabio Maulo <[email protected]> wrote: > 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 -- Hide quoted text - > > - Show quoted text -
