On Thursday, August 11, 2016 at 8:35:32 AM UTC-4, Oskar Berggren wrote:
>
>
>
> 2016-08-11 13:25 GMT+01:00 mwpowellhtx <mwpow...@gmail.com <javascript:>>:
>
>>
>>
>> On Thursday, August 11, 2016 at 8:05:04 AM UTC-4, Oskar Berggren wrote:
>>>
>>>
>>>
>>> 2016-08-11 12:59 GMT+01:00 Oskar Berggren <oskar.b...@gmail.com>:
>>>
>>>
>>>>
>>>> 2016-08-11 11:47 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Wednesday, August 10, 2016 at 1:20:15 PM UTC-4, Oskar Berggren
>>>>> wrote:
>>>>>>
>>>>>> You can put something like this in relevant base class:
>>>>>>
>>>>>> public TCastTarget As<TCastTarget>()
>>>>>> {
>>>>>> return (TCastTarget)this;
>>>>>> }
>>>>>>
>>>>>
>>>>> Do you understand what's going on with Proxying? You don't see it in
>>>>> your code, but what you end up with is something like this:
>>>>>
>>>>> class JuiceProxy : Juice { ... }
>>>>> class AppleJuiceProxy : AppleJuice { ... }
>>>>> class OrangeJuiceProxy : OrangeJuice { ... }
>>>>>
>>>>> Something like that, if memory serves, but I haven't verified the
>>>>> actual inheritance tree.
>>>>>
>>>>> And since Cup wants a Juice, JuiceProxy fits the bill, but there is no
>>>>> reasonable way for JuiceProxy to be side-cast into the expected
>>>>> AppleJuice,
>>>>> much less AppleJuiceProxy, without losing necessary hierarchical details.
>>>>>
>>>>
>>>>
>>>> If you have
>>>> AppleJuice : Juice
>>>>
>>>> you will get
>>>> JuiceProxy : Juice
>>>>
>>>> but the important thing is that if you call a method on Juice:
>>>> myJuice.As<AppleJuice>()
>>>>
>>>> then if myJuice is a JuiceProxy, it will override the As<>() method,
>>>> trigger any required initialization, AND THEN FORWARD THE CALL TO THE REAL
>>>> OBJECT. And the real object will be an instance of AppleJuice. So when the
>>>> body of the As() method runs, the this-pointer will be the real, derived,
>>>> object, that you can cast.
>>>>
>>>>
>>>>
>>>
>>> For comparison, consider this:
>>>
>>> class Juice { public abstract string GetColor(); }
>>> class AppleJuice { public override string GetColor() { return
>>> "brown-semi-transparent"; } }
>>> class OrangeJuice { public override string GetColor() { return
>>> "yellow"; } }
>>>
>>>
>>> If you now do:
>>> juiceProxy.GetColor();
>>>
>>> clearly you would expect it to return the correct color as per above?
>>> And it will. Thus proving that there is a "hidden" instance of the correct
>>> type. The As() method I showed exploits this by simply delegating the
>>> casting to the object itself (the real object, not the proxy).
>>>
>>
>> That doesn't prove a thing. All that shows is that the proxy override the
>> method. Because an AppleJuiceProxy is still an AppleJuice; but a JuiceProxy
>> is not necessarily an AppleJuiceProxy. In fact, it is not, by the .NET type
>> system.
>>
>>
> Oh my god, it proves everything! In the sample I meant that the
> juiceProxy instance is of class *JuiceProxy*. In this example there is no
> "AppleJuiceProxy" at all. Internally a proxy will contain a reference to an
> instance of the real object (AppleJuice or OrangeJuice) - thus making it
> possible for the call on the proxy to internally reach the correct
> implementation. (The real object instance will be generated the first time
> it's needed, by loading the object from the database - at this time
> NHibernate knows the proper derived type and is therefore able to
> instatiate the correct subclass.)
>
Maybe I didn't explain it well, but that's where we started if you read my
OP. JuiceProxy can't be cast to an AppleJuice. Because of the proxy/.NET
type system, that kind of makes sense, but makes it interesting, at best,
to support polymorphic/casting testing for AppleJuice things, depending
whether Juice is/was an AppleJuice.
So as you say, you can't cast an instance of JuiceProxy to a derived type,
> but *you can* *extract the real object* from the proxy and then cast
> that. This is what the various "tricks" I've shown you do.
>
Yes, I appreciate that. I'm investigating that avenue.
--
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fluent-nhibernate+unsubscr...@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.
Visit this group at https://groups.google.com/group/fluent-nhibernate.
For more options, visit https://groups.google.com/d/optout.
