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

Fixed typo

Browse Source 
Author:manus
Date:2010-10-26T15:19:21.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@689 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
manus
2010-10-26 15:19:21 +00:00
parent 508c45c54e
commit d656f51598
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
View File

@@ -70,7 +70,7 @@ This change works for all the generic classes in EiffelBase ... except for one:
</code>
we create <code>my_array</code> with one hundred <code>INTEGER</code> elements. <code>INTEGER</code> is an expanded type, and each element is initialized by applying the default initialization rule for <code>INTEGER</code>, i.e, the integer representation of zero.
However, if <code>my_array</code> had been declared of a type with reference semantics, say <code>STRING</code> (meaning, or course, <code>attached STRING</code>, the default rule would not work well, because the default initialization for references types is <code>Void</code> which would not be allowed in an array of elements of any attached type.
However, if <code>my_array</code> had been declared of a type with reference semantics, say <code>STRING</code> (meaning, of course, <code>attached STRING</code>, the default rule would not work well, because the default initialization for references types is <code>Void</code> which would not be allowed in an array of elements of any attached type.
The solution to this challenge is fairly simple. For arrays of elements of detachable or expanded types, there is no different behavior. When dealing with arrays of elements of attached types, we must be careful.
@@ -95,7 +95,7 @@ Upon creation, each element of the array will reference the same object; an obje
==Using the ''attribute'' keyword carefully==
The keyword <code>attribute</code> is should be used with some care. You might be tempted to think that it would be convenient or add an extra element of safety to use self-initializing attributes widely. And in a way, you would be correct. But you should also understand that there is a price to pay for using self-initializing attributes and stable attributes. It is that upon every access, an evaluation of the state of the attribute must be made. So, as a general rule, you should avoid using self-initializing attributes only for the purpose of lazy initialization.
The keyword <code>attribute</code> should be used with some care. You might be tempted to think that it would be convenient or add an extra element of safety to use self-initializing attributes widely. And in a way, you would be correct. But you should also understand that there is a price to pay for using self-initializing attributes and stable attributes. It is that upon every access, an evaluation of the state of the attribute must be made. So, as a general rule, you should avoid using self-initializing attributes only for the purpose of lazy initialization.
==More about the ''attached syntax''==