On Thu, 2007-02-15 at 09:32 -0800, Daniel F Moisset wrote:
> Result := Precursor (other)
>
> which executes the Precursor of is_equal (the one defined in PARENT).
> This call returns True, and then checks its postcondition "symmetric".
> Given that Result = True, it checks that "other.is_equal (Current)".
> That call, given that Current and other are different (and
> CHILD.is_equal checks that property which makes them different after
> the call to Precursor), returns False, so we have a postcondition
> failure.
>
> So, my question is:
> * Is this a language gotcha? (I found this weird, didn't know about
> it)
I guess it is.
> * Is it a bug of my implementation, because calls from Precursor call
> should be made using the Precursor type instead of dynamic type (sound
> very non-OOish, but would make this case work)
I don't think so, if Precursor is inherited covariantly. Then the
"Precursor type" isn't PARENT (which I think is also what Peter Horan
says), and other is alway polymorphic within is_equal anyway...
I like it when I can name the specific type of
an object when I know it, why not? I tried with "if same_type(other)"
and/or expanded objects of types PARENT and ANY, hoping I could
make objects of a statically known type for comparison,
but didn't get really far. (BTW assignment between expanded and
reference isn't accepted by the compiler in
expanded_obj := obj_ref
Has there been a change?)
> * Is this a conceptual mistake of mine, the way I am trying to do
> things?
Is there a way to invoke a specific routine x.f up x's type
hierarchy? If not, then I think the post-condition says something
about possibly different objects, really.
|
