Eiffel Breaking Changes - Revision history

Manus: /* Strings: remove implicit conversion STRING_32.as_string_8 */

2016-01-29T12:31:09Z

‎Strings: remove implicit conversion STRING_32.as_string_8

Manus: /* Strings: remove implicit conversion STRING_32.as_string_8 */

2016-01-29T12:30:26Z

‎Strings: remove implicit conversion STRING_32.as_string_8

Jfiat: /* Library changes */

2016-01-28T13:50:21Z

‎Library changes

Manus: /* File operations */

2016-01-23T13:34:05Z

‎File operations

Manus: /* Change dynamic type of objects */

2016-01-23T13:30:00Z

‎Change dynamic type of objects

Manus: /* Restrict export to copy */

2016-01-23T13:16:07Z

‎Restrict export to copy

Manus: /* Void-safe copy */

2016-01-23T13:08:46Z

‎Void-safe copy

Alexander Kogtenkov: /* Library changes */ Added 2 notes for issues involving TUPLE.

2016-01-22T16:49:17Z

‎Library changes: Added 2 notes for issues involving TUPLE.

Manus: /* Introduction */

2016-01-21T13:10:06Z

‎Introduction

Manus: /* Library changes */

2016-01-21T13:04:53Z

‎Library changes

@@ Line 31: / Line 31: @@
 A lot of code would not compile anymore by this change. Pretty much all libraries would have to be rewritten.
-==Strings: remove implicit conversion STRING_32.as_string_8 ==
+==Strings: remove implicit conversion from XXX_STRING_32 to XXX_STRING_8==
 ===Before===
 XXX_STRING_32 implicitly converts to XXX_STRING_8.

@@ Line 33: / Line 33: @@
 ==Strings: remove implicit conversion STRING_32.as_string_8 ==
 ===Before===
-STRING_32 implicitly converts to (READABLE_)STRING_8.
+XXX_STRING_32 implicitly converts to XXX_STRING_8.
 ===After===
-no more STRING_32 to STRING_8 implicit conversion.
+No more XXX_STRING_32 to SSS_STRING_8 implicit conversion.
-===Rational===
+===Rationale===
-This implicit conversion is highly dangerous with unicode string, since it will replace silently any unicode char by null char %U. And thus lost of information.
+This implicit conversion was great when the STRING_32 type was introduced in Eiffel and heavily used in EiffelVision2. It enabled existing code that was purely ASCII at the time to compile unchanged. The goal was always to remove that conversion as early as possible as it is a truncation which was ok as long as your were ASCII based.
-This is a source of nasty bug. One can check the callers with EiffelStudio and check for each cases, but not nice.
-===Issues===
+Now this is a recipe for trouble to allow such an implicit conversion.
-A lot of code would not compile anymore by this change. Pretty much all libraries would have to be rewritten.
 ==Void-safe and invariant-safe copy==

@@ Line 30: / Line 30: @@
 ===Issues===
 A lot of code would not compile anymore by this change. Pretty much all libraries would have to be rewritten.
 ==Void-safe and invariant-safe copy==

@@ Line 104: / Line 104: @@
 * Storables won't be retrievable by old systems
-==File operations==
+==I/O and external operations==
 ==Remove explicit creation procedure from <e>TUPLE</e>==

@@ Line 85: / Line 85: @@
 For client code, it should still compile as before. For user defined code that is known to allow copy/duplication, the code will have to be rewritten to allow copy/duplication.
-==Change dynamic type of objects==
+==Change the type describing the dynamic type of objects==
 ==File operations==

← Older revision		Revision as of 13:16, 23 January 2016
Line 70:		Line 70:

	==Restrict export to copy==		==Restrict export to copy==
		+	===Before===
		+	You could duplicate objects as you wish.
		+	===After===
		+	You can only duplicate objects if they are marked as `copiable' or `duplicable'. So far there is no definite answer to allow this. What is being proposed is either one of the following:
		+	# Define '''twin''', '''copy''', ... in ANY like today, but exported to NONE.
		+	# Remove '''twin''', '''copy''', ... from ANY and add them to a new abstract class COPIABLE
		+	The second solution is simple as at runtime we simply have to check for conformance to COPIABLE.
		+	===Rationale===
		+	If you duplicate an object graph that has some external memory reference, causing a duplication of the object holding that reference could cause a double-free of that external memory reference when Eiffel objects are disposed by the GC.
		+
		+	In addition, some objects are complicated to duplicate such as: Files, Windows, Widgets, databases connections,...
		+
		+	===Issues===
		+	For client code, it should still compile as before. For user defined code that is known to allow copy/duplication, the code will have to be rewritten to allow copy/duplication.

	==Change dynamic type of objects==		==Change dynamic type of objects==

← Older revision		Revision as of 16:49, 22 January 2016
Line 47:		Line 47:

	==File operations==		==File operations==
		+
		+	==Remove explicit creation procedure from <e>TUPLE</e>==
		+	'''Scope:''' void-safety
		+	====Before====
		+	====After====
		+	====Rationale====
		+	Explicit creation of a <e>TUPLE</e> with attached reference fields introduces objects that break void-safety rules and make a system void-unsafe.
		+	====Issues====
		+	Some code needs to be redesigned to remove explicit <e>TUPLE</e> creation.
		+	====Impact====
		+	Low: explicit tuple creation can be flagged as obsolete by using regular Eiffel mechanism. After 1-2 releases the feature can be removed.
		+
		+	==Make <code>TUPLE</code> argument of features <code>{ROUTINE}.call</code> and <code>{FUNCTION}.item</code> attached==
		+	'''Scope:''' void-safety
		+	====Before====
		+	<code>{ROUTINE}.call</code> and <code>{FUNCTION}.item</code> take argument of a type <code>detachable TUPLE</code>.
		+	====After====
		+	<code>{ROUTINE}.call</code> and <code>{FUNCTION}.item</code> take argument of a type <code>TUPLE</code>.
		+	====Rationale====
		+	It is possible that an agent object expects some arguments, but if it is passed <e>Void</e>, the compiler does not warn user about the issue.
		+	====Issues====
		+	All calls <e>.call (Void)</e> and <e>.item (Void)</e> need to be updated.
		+	====Impact====
		+	Very low: code can be updated by replacing <e>.call (Void)</e> with <e>.call</e>.

	=Language Change=		=Language Change=

@@ Line 5: / Line 5: @@
 =Introduction=
-As of this writing, January 21st 2016, the Eiffel language has slowly evolved over the years and added numerous new facilities. Initially, the changes were done by Eiffel Software while maintaining backward compatibility. Then, a major work was done between 2001 and 2005 to standardize the language which became an ECMA standard in 2005 ([http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA-367]) and an ISO standard in 2006 ([http://www.iso.org/iso/catalogue_detail.htm?csnumber=42924 ISO/IEC 25436:2006]). That work established some constructs initially implemented in EiffelStudio and also introduced some new ones. Most of the changes introduced by the standardization have been implemented but there are quite a few remaining. In some cases, it is due to the ration cost/benefit of the implementation, in some others it is a breaking changes.
+As of this writing, January 21st 2016, the Eiffel language has slowly evolved over the years and added numerous new facilities. Initially, the changes were done by Eiffel Software while maintaining backward compatibility. Then, a major work was done between 2001 and 2005 to standardize the language which became an ECMA standard in 2005 ([http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA-367]) and an ISO standard in 2006 ([http://www.iso.org/iso/catalogue_detail.htm?csnumber=42924 ISO/IEC 25436:2006]). That work established some constructs initially implemented in EiffelStudio and also introduced some new ones. Most of the changes introduced by the standardization have been implemented but there are quite a few remaining. In some cases, it is due to the ration cost/benefit of the implementation, in some others it is a breaking changes. In addition, since the standardization was completed, Eiffel Software kept adding new language features too.
 This page is going to list all the changes that needs to be done by Eiffel Software to conform to the standard which cover both the language but also the library facilities required to support the language specification.

@@ Line 43: / Line 43: @@
 ==Restrict export to copy==
 ==Change dynamic type of objects==
 =Language Change=