2016-08-11 14:05 GMT+01:00 mwpowellhtx <mwpowell...@gmail.com>:
>
>
> On Thursday, August 11, 2016 at 8:47:18 AM UTC-4, Oskar Berggren wrote:
>>
>>
>>
>> 2016-08-11 13:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:
>>
>>>
>>>
>>> On Thursday, August 11, 2016 at 8:22:07 AM UTC-4, Oskar Berggren wrote:
>>>>
>>>>
>>>>
>>>> 2016-08-11 12:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Thursday, August 11, 2016 at 7:23:35 AM UTC-4, Rasmoo wrote:
>>>>>>
>>>>>> That's exactly Oskar's trick: You call the proxy, into the proxied
>>>>>> object and get it to cast itself.
>>>>>>
>>>>>
>>>>> No, that's not what Oskar wrote, one the one hand; see below:
>>>>>
>>>>> public TCastTarget As<TCastTarget>()
>>>>> {
>>>>> return (TCastTarget)this;
>>>>> }
>>>>>
>>>>> This is not any different than what I attempted in the LINQ statement.
>>>>>
>>>>
>>>> It is in fact completely different. It is applying the cast to an
>>>> entirely different object.
>>>>
>>>
>>> How so? Watch what I did there.
>>>
>>> cup.Juice is a type of Juice, correct?
>>>
>>
>>
>> In this line you are attempting to cast the juiceProxy, which as expected
>> won't work:
>>
>>> So I want ((AppleJuice) cup.Juice). With me so far?
>>>
>>
>>
>> But here, you need to take a moment to ponder which object the "this"
>> pointer *really* points to:
>>
>>> Adding Juice.As<TJuice>() { return (TJuice) this; } is no different than
>>> doing the cast external to the instance.
>>>
>>
>> Hint: It is NOT the proxy instance.
>>
>> In memory you will have
>> proxyInstance [points to]-> realInstance (realInstance present
>> _after_ it's been required for the first time)
>>
>> And the call path will be something like this:
>> proxyInstance.As<ConcreteType>() [calls]->
>> realInstance.As<ConcreteType>() { so when code here runs, "this" is
>> realInstance, not proxyInstance }
>>
>>
>> So as I said, the cast is being applied to a completely different object,
>> compared to when you apply the cast "externally". And that is a very
>> important difference, because it will actually work.
>>
>
> I had to prove it to myself, but yes, I am starting to see that using a
> couple different test cases involving an array of LINQ selected instances,
> which are JuiceProxy at the array level, but which seem to be AppleJuice
> within each element. Also accessing which "this", within the implemented
> class, not the proxy/wrapper (more of a wrapper than an inherited class at
> that moment). The proxies can get one cross eyed real fast though to be
> sure.
>
Cool! :)
/Oskar
--
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.
