diff --git a/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki b/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki index 0352448e..ee3ef706 100644 --- a/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki @@ -80,7 +80,7 @@ In the project settings for the target in which you are working: # Set '''Void safe''' to either '''Complete void safety''' or '''On demand void safety'''. # Set '''Are types attached by default?''' to '''True'''. -{{note|Remember that during a transitional period starting with V6.4, there will be multiple versions of the configuration files for Eiffel libraries and precompiles. For example, base.ecf (non-void-safe) and base-safe.ecf (void-safe). It is expected that in the future there will only be one configuration file (e.g., base.ecf) that will work with both void-safe and non-void-safe client software. }} +{{note|Remember that during a transitional period starting with V6.4, there will be multiple versions of the configuration files for Eiffel libraries and precompiles. For example, base.ecf (void-unsafe) and base-safe.ecf (void-safe). It is expected that in the future there will only be one configuration file (e.g., base.ecf) that will work with both void-safe and void-unsafe client software. }} If necessary, remove Eiffel libraries and any precompiled library that your project uses and re-add them with their void-safe configuration files. Because you've set your target to void-safety, when you click '''Add Library''', you should see only void-safe configurations by default. You will see a check box on the dialog that you can uncheck if you want to see all available library configurations: diff --git a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki index 7451c65c..e6e6b3c9 100644 --- a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki @@ -7,7 +7,7 @@ Now that we've been introduced to the Eiffel void-safe facilities, let's look at ==Project settings for void-safe projects== -There are three project settings that are related to void-safety. These settings can be set with great granularity throughout your project to allow you maximum flexibility, particularly when including classes or libraries that are non-void-safe or that have been converted to void-safety, but must do double duty in the void-safe and non-void-safe worlds. +There are three project settings that are related to void-safety. These settings can be set with great granularity throughout your project to allow you maximum flexibility, particularly when including classes or libraries that are void-unsafe or that have been converted to void-safety, but must do double duty in the void-safe and void-unsafe worlds. ===The ''"Void-safe"'' setting=== @@ -50,7 +50,27 @@ This setting instructs the compiler to recheck inherited features in descendant As of EiffelStudio version 6.4, the majority of the libraries distributed with EiffelStudio are void-safe. -{{note|During a period of transition, there will be different Eiffel configuration files (.ecf's) for non-void-safe and void-safe projects (for example, base.ecf and base-safe.ecf). If you have set the '''Void-safe''' setting to check for void-safety, then when you add a library to your project in EiffelStudio, you will see only the void-safe configurations by default. After the transition period, it is expected that there will be only one version of each of the configuration files for each library. The single configuration files will serve both non-void-safe and void-safe projects. }} +{{note|During a period of transition, there will be different Eiffel configuration files (.ecf's) for void-unsafe and void-safe projects (for example, base.ecf and base-safe.ecf). If you have set the '''Void-safe''' setting to check for void-safety, then when you add a library to your project in EiffelStudio, you will see only the void-safe configurations by default. After the transition period, it is expected that there will be only one version of each of the configuration files for each library. The single configuration files will serve both void-unsafe and void-safe projects. }} + +===Using generic classes=== + +Void-safety affects generic classes. Fortunately, from the viewpoint of those writing clients to the generic classes in the EiffelBase library, not much has changed. Still, you should understand the interplay between void-safety and [[ET: Genericity and Arrays|genericity]]. + +Consider a generic class like LIST [G]. The formal generic parameter G represents an arbitrary type. In a generic derivation of LIST [G], say LIST [STRING], the formal generic type is replaced by an actual generic type, in this case STRING. + +Remember that unconstrained genericity, LIST [G], for example, is really a case of [[ET: Inheritance#Constrained genericity|constrained genericity]] in which the generic parameter is constrained to ANY, that is, it could be written LIST [G -> ANY]. + +With the advent of void-safe Eiffel, the unconstrained generic class name LIST [G] now equates to LIST [G -> detachable ANY]. Because any type, say T, (synonymous with attached T in void-safe Eiffel) conforms to detachable T, this change facilitates the production of generic classes, but has little effect on writers of clients to those classes. + +This change works for all the generic classes in EiffelBase ... except for one: ARRAY. Arrays are a special case because we often create arrays with a pre-allocated number of elements. In the case of expanded types, there's not a problem. For example, in this code + + my_array: ARRAY [INTEGER] + ... + create my_array.make (1, 100) + +we create my_array with one hundred INTEGER elements. Each element is initialized by applying the default initialization rule for INTEGER. + +However, if my_array had been declared of a type with reference semantics, say STRING, the default rule would not work well, because the default initialization for references types is Void. ==Using the ''attribute'' keyword carefully== @@ -320,7 +340,7 @@ Also, you should remember that unlike other attributes, you can access stable at my_stable_attribute: detachable SOME_TYPE note - options: stable + option: stable attribute end diff --git a/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki b/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki index 950fc608..260ac7f3 100644 --- a/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki @@ -96,7 +96,7 @@ So, for a local variable l_string, the following is valid: ... -But, if l_string had been a target of an assignment in which the source could possibly have been void, then it could no longer be guaranteed that l_string is non-void. So, assuming that my_detachable_string is an attribute declared as type detachable STRING, the second application of append in this example would be invalid: +But, if l_string had been a target of an assignment in which the source could possibly have been void, then it could no longer be guaranteed that l_string is not void. So, assuming that my_detachable_string is an attribute declared as type detachable STRING, the second application of append in this example would be invalid: local