Re: [Modeling-users] inheritance and relations confusion

[Sebastien B. <sbi...@us...>]

        Hi,

> thanks for taking the time to clarify this issue... given that it seems t=
hat
> others are not often surprised by this, and that making this automatic
> will result in unnecessary overhead, I would be in favour of just clarify=
ing
> 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.

  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.

> > Now if you clear the fault (b.willRead()), then b.getAs() works as
> > expected.
>=20
> Fine. At the moment, the (default) code that gets executed when
> a.getB() is called is something like:
>=20
>    def getB(self):
>      "Return the b relationship (toOne)"
>      self.willRead()
>      return self._b
>=20
> But, what's wrong with doing something like (only when an entity
> participates in an inheritance hierarchy) ?
>=20
>    def getB(self):
>      "Return the b relationship (toOne)"
>      self.willRead()
>      b =3D self._b
>      b.willRead()
>      return b
>=20
> 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 ?))

[...]
> 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...
=20
    Sorry for having obfuscated rather than clarifying the
  subject...  Luckyly you were attentive on this one.

-- S=E9bastien.