Re: [Modeling-users] inheritance and relations confusion

[Mario R. <ma...@ru...>]

Hello!

thanks for the reply! Oh, btw, the little reorganization changes
you made on the public web site are a good improvement in my opinion...

>> thanks for taking the time to clarify this issue... given that it 
>> seems that
>> others are not often surprised by this, and that making this automatic
>> will result in unnecessary overhead, I would be in favour of just 
>> clarifying
>> when this may happen, and how to deal with it (also in the form of a
>> nice faq...)
>
> Seems reasonable, esp. in the light of what follows...
>
>> Having said this, I still do not fully buy the performance overhead
>> argument. See comments below...
> [snipped]
>> In this particular model, [containing just A and B]
>> it is categoric that an A is related to a B (or,
>> I guess, a sub-class of B, but not a super-class of B!).
>> So, I still do not see why an A is returned, as this does not
>> conform to the model -- thus I see this as incorrect behaviour.
>
> Okay... In fact, I realize that I did not explain the right thing 
> --what
> I explained is more a reason on why the GlobalID for a fault is related
> to the root entity, than a reason why the fault itself is an instance 
> of
> the root class.

Ah, OK.

>   I understand your point and agree that this can be seen as an
>   incorrect behaviour. I need to investigate on that, to see if fixing
>   this could be a problem in any way (incl. time overhead) --I dunno 
> for
>   now.

Look forward to what you find out and the estimation for changing this.

>>> Now if you clear the fault (b.willRead()), then b.getAs() works as
>>> expected.
>>
>> Fine. At the moment, the (default) code that gets executed when
>> a.getB() is called is something like:
>>
>>    def getB(self):
>>      "Return the b relationship (toOne)"
>>      self.willRead()
>>      return self._b
>>
>> But, what's wrong with doing something like (only when an entity
>> participates in an inheritance hierarchy) ?
>>
>>    def getB(self):
>>      "Return the b relationship (toOne)"
>>      self.willRead()
>>      b = self._b
>>      b.willRead()
>>      return b
>>
>> This method is not called all the time b needs to be accessed (as in
>> the examples you cite below, right?), so the performance hit 
>> (associated
>> with the _getattr_ suggestion) is minimal. Or am I being too naive 
>> here?
>
> You're not ;) But why do you insist that we make it simple when we can
> make it complex ?))

Because I'm just a simple guy...  ( ... I live from day to day,
A ray of sunshine melts my frown,  and blows my blues away... ;)

> [...]
>> Other than the a.getB() explicit calls in client code, when is this
>> method called within the framework?
>
>   --> In fact you're absolutely right, and the framework will not call
>       this on its own: remember that the mdl. uses KeyValueCoding to
>       access properties, and only private methods (storedValueForKey),
>       so when obj._prop and obj.getProp() are defined, it always
>       accesses obj._prop and never calls obj.getProp().
>
>   Plus, your method is crystal-clear, and does not require any complex
>   inspection of subclasses or whatsoever...
>
>     Sorry for having obfuscated rather than clarifying the
>   subject...  Luckyly you were attentive on this one.

Great. Nice to know that sometimes my gut feeling that things
need not be complicated turns out to be correct ;) Unfortunately
this is not always the case ;(

Cheers, mario