Difference between revisions of "Talk:Eiffel Breaking Changes"
(Started a discussion on void safe copy.) |
m (Cosmetics.) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
==Void-safe copy== | ==Void-safe copy== | ||
| + | '''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] ([[User talk:Alexander Kogtenkov|talk]]) 08:21, 22 January 2016 (PST)''' | ||
| + | |||
Possible approaches: | Possible approaches: | ||
{| class="wikitable" border="1" style="border-collapse:collapse; border-color: LightGrey;" | {| class="wikitable" border="1" style="border-collapse:collapse; border-color: LightGrey;" | ||
Latest revision as of 07:21, 22 January 2016
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.
|
|
|
Remove copy altogether. Add a class CLONEABLE with a deferred feature twin.
|
Expanded classes should inherit CLONEABLE (and define twin).
|
|
|
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.
