mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 15:22:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:manus

Browse Source 
Date:2010-11-23T08:24:23.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@701 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
manus
2010-11-23 08:24:23 +00:00
parent 8d996fa69b
commit 87215d4b17
6 changed files with 2 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki
View File

@@ -5,9 +5,6 @@
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Support for new expanded semantics defined in ECMA-367.==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Support for new expanded semantics defined in ECMA-367. The current limitations are: no copy semantics in the .NET code generation, and still no generic conformance.
* Inline agents as defined in ECMA-367 with the limitation to only accept the do form.
* Added possibility to define agents on attributes or externals.

6
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki
View File

@@ -8,12 +8,6 @@
* Added support for multiple constraints in formal generic parameters.
* The root class can now be a generic class, and thus one can now specify a root type.
* The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
* Added experimental option for full class checking. It can be enabled at the system, cluster or class level.==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Added support for multiple constraints in formal generic parameters.
* The root class can now be a generic class, and thus one can now specify a root type.
* The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
* Added experimental option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries. The next release should fix all the remaining issues.
* Integers can now also be specified with binary and octal representation.
* Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit.

5
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki
View File

@@ -7,11 +7,6 @@
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Multiple errors are reported for each compilation degree.
* Experimental support for Non-conforming Inheritance has been added (Classic only). Classes may now be inherited (using inherit {NONE} but no conformance of that class is implied.
* Attachment marks are supported.==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Multiple errors are reported for each compilation degree.
* Experimental support for Non-conforming Inheritance has been added (Classic only). Classes may now be inherited (using inherit {NONE} but no conformance of that class is implied.
* Attachment marks are supported. Now it's possible to specify whether an entity is attached or detachable:
<code>a: !A -- a cannot be used before it is attached
b: ?A -- b can be used before it is attached</code>

7
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki
View File

@@ -9,13 +9,6 @@
* Added support for new ~ operator which can compare 2 objects safely regardless of their type.
* Added detection of harmful catcall at runtime (harmless ones are currently ignored).
* Added support for `note' keyword with a migration path in case `note' is being used as an identifier in your code.
* Added `-gc_stats' option to get some information on how much CPU==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Exceptions as objects are now implemented.
* Added support for new ~ operator which can compare 2 objects safely regardless of their type.
* Added detection of harmful catcall at runtime (harmless ones are currently ignored).
* Added support for `note' keyword with a migration path in case `note' is being used as an identifier in your code.
* Added `-gc_stats' option to get some information on how much CPU time is spent in GC during an Eiffel compilation.
* Introduced several new much more powerful CAPs that now can be applied not only to read-only entities, but also to local variables (including <code>Result</code>), and can take into account execution paths as well as some obvious void-safe patterns.

2
documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-62-and-ise-eiffel-63.wiki
View File

@@ -7,7 +7,7 @@
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Implemented proper runtime conformance for attached types, that is to say A [!ANY] will conform to A [!ANY] or A [?ANY], but A [?ANY] will only conform to A [?ANY].
* Added support for the new <eiffel>attriibute</eiffel> keyword (support is enabled when using the standard syntax option, i.e. the same option that allows you to use the <eiffel>note</eiffel> keyword.
* Added support for the new <eiffel>attribute</eiffel> keyword (support is enabled when using the standard syntax option, i.e. the same option that allows you to use the <eiffel>note</eiffel> keyword.
==Improvements==
* Improved speed of compiler by about 10% overall.

2
documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki
View File

@@ -176,7 +176,7 @@ Still, it's not too hard to understand the basics of initializing variables of a
===Self-initializing attributes===
A self-initializing attribute is guaranteed to have a value when accessed at run time. Declarations of self-initializing attributes are characterized by the use of <code>attribute</code> keyword. The code that follows the <code>attribute</code> keyword is executed to initialize the attribute in the case that the attribute is accessed prior to being initialized in any other way.
A self-initializing attribute is guaranteed to have a value when accessed at run time. Declarations of self-initializing attributes are characterized by the use of the <code>attribute</code> keyword. The code that follows the <code>attribute</code> keyword is executed to initialize the attribute in the case that the attribute is accessed prior to being initialized in any other way.
So, self-initializing attributes are ordinary attributes, with the restriction that they are of both ''attached'' types and ''reference'' types (i.e., not expanded types or constants). Self-initializing attributes still can be, and typically will be initialized in the traditional ways. The difference is that the code in the attribute part serves as a kind of safety net guaranteeing that a self-initializing attribute will never be void, even if it is accessed prior to being initialized by one of the traditional means.