Talk:Eiffel Breaking Changes

Revision as of 07:21, 22 January 2016 by Alexander Kogtenkov (Talk | contribs) (Cosmetics.)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Void-safe copy

Alexander Kogtenkov (talk) 08:21, 22 January 2016 (PST)

Possible approaches:

Solution Rules for expanded classes Pros Cons
Remove clone altogether and make copy a creation procedure where needed. copy is a mandatory creation procedure for expanded classes. Then reattachment to an expanded entity means creation of an expanded object with regular creation rules.
  • No magic.
  • No special run-time support.
  • Partial code duplication for every class (Precursor can be used to reduce duplication).
Remove copy altogether. Add a class CLONEABLE with a deferred feature twin. Expanded classes should inherit CLONEABLE (and define twin).
  • No magic.
  • Code duplication for every class.

Special rules for expanded classes can be removed altogether. Instead additional requirements will be added:

  • reattachment with a source of an expanded type is valid only if ...
  • actual generic of an expanded class is valid only if ...
  • changing a type in a declaration from reference to expanded is valid only if ...

where ... is as specified in the Rules for expanded classes above. This would allow to have expanded classes that cannot be copied and this may be useful in some scenarios.