Re: [freeelks-devel] Implementation of {ANY}.copy

[Eric B. <er...@go...>]

Alexander Kogtenkov wrote:
> My feeling is that this is not
> so straightforward because of dynamic dispatch. For
> example, a call to feature `f (other: like Current)' could
> actually mean a call to `standard_copy' in a class that
> merges the features into one.

Likewise for `copy'.

> If reattachment was specified in terms of `twin' instead,
> it would be possible to avoid reattachment by using a
> creation instruction as in
> 
>     twin: like Current is
>         do
>             create Result.make (...)
>             Result.set (...)
>             ...
>         end

This means that you have a `set' routine which is
able to set private attributes as well as exported
ones. I discussed about that with Manu and my conclusion
was that most of the time `twin' would be implemented
as follows in class A:

    twin: like Current is
        do
            create Result.make_from_a (Current)
        end

where `make_from_a' would have an implementation
not that different from what we currently have
in `copy'. So this is just moving the problem
rather than solving it, although I understand
that with your solution we can go around it with
some awkward implementation:

    twin: like Current is
        do
            create Result.make
            Result.set_private_attribute1 (private_attribute1)
            Result.set_private_attribute2 (private_attribute2)
            ...
            Result.set_private_attributen (private_attributen)
        end

> Finally, reattaching expanded objects to reference entities
> in the current specification preserves expanded semantics.
> But this can cause a working code to fail. For example, if
> we consider the following routine
> 
>     update (a: A) is
>         do
>             a.put (value)
>         ensure
>             a.item = value
>         end
> 
> (where A is a reference type) and the code that calls it
> 
>     update (a)
>     check
>         a.item = value
>     end
> 
> then if `a' is attached to an expanded descendant of A,
> the check instruction would cause assertion violation
> because a clone would be passed to `update' instead
> of the original object and the original object would not
> be updated.

With ECMA Eiffel we have the copy-semantics if `a' is
attached to an expanded descendant of A. So yes, the
check-instruction is violated. But it was violated as
well before ECMA Eiffel because we have some sort of
conversion of the expanded object to its reference type
when passing it as argument of `update'. So I don't
see why you say that "this can cause a working code
to fail". Or aren't you comparing ECMA with ETL2?
If what you mean by "working code" is that it works
if `a' is attached to a reference type, then we also
have other weird cases like that, where for example
`a' is converted when passed as argument of some
`update' features. We also have things like that:

    a.b.set_item (2)
    check
       a.b.item = 2
    end

which is not true when `b' is expanded.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com