mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-06 14:52:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update wikipage Release notes for EiffelStudio 17.01. (Signed-off-by:jocelyn).

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1729 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
2017-01-18 15:18:57 +00:00
parent 4bedf576fd
commit f8080c0859
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/trunk/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.01.wiki
View File

@@ -20,7 +20,7 @@
*
==Compiler==
* Added notion of '''capability''' for specifying what settings a particular '''library supports'''. The key advantage is that even if you compile in different settings and use libraries with different properties (for void safety, SCOOP concurrency etc.) you can now use a '''single ECF''' (Eiffel Control File) rather than maintaining different ECFs for different configurations. This mechanism fulfills a wish often expressed by Eiffel developers, particularly those in charge of large applications. At the moment the settings include cat-call detection, concurrency and void safety. A project or a library with a specific setting cannot rely on a library with insufficient capabilities.
* Added notion of '''capability''' for specifying what settings a particular '''library supports'''. The key advantage is that even if you compile in different settings and use libraries with different properties (for void safety, SCOOP concurrency etc.) you can now use a '''single ECF''' (Eiffel Configuration File) rather than maintaining different ECFs for different configurations. This mechanism fulfills a wish often expressed by Eiffel developers, particularly those in charge of large applications. At the moment the settings include cat-call detection, concurrency and void safety. A project or a library with a specific setting cannot rely on a library with insufficient capabilities.
* Configuration option "Are types attached by default?" defaults to True when reading non-void-safe projects so that if the project is changed to be void-safe, the recommended default for attachment status of class types without marks is used.
* Removed a possibility to set void safety level for a specific class or cluster, it can be done only for a whole library or project.