diff --git a/documentation/current/method/void-safe-programming-eiffel/index.wiki b/documentation/current/method/void-safe-programming-eiffel/index.wiki index 8a37c0d5..2c5302f4 100644 --- a/documentation/current/method/void-safe-programming-eiffel/index.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/index.wiki @@ -22,5 +22,7 @@ The result is that we must consider certain questions: # What do I need to know to produce standard Eiffel software? # What do I need to know to convert my existing systems to be standard? +To find some answers, continue reading this chapter. + diff --git a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki index 6464e71a..e50ae033 100644 --- a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki @@ -95,17 +95,17 @@ By using the '''attached syntax''', we can perform an '''object test''' on a var l_x.f (a) end -In the example above, x is tested to make certain that it is attached. If so, the local l_x is created and can be used safely even if x is a class attribute. So, the attached syntax, is really another CAP, because it provides a clearly verifiable place for the application of features to targets that are guaranteed not to be void. +In the example above, x is tested to make certain that it is attached. If so, the local l_x is attached to the same object as x and can be used safely even if x is a class attribute. So, the attached syntax, is really another CAP, because it provides a clearly verifiable place for the application of features to targets that are guaranteed not to be void. {{note|The attached syntax has other syntax variations as well as other uses. These will be discussed later. }} -One way to make sure we comply with the target rule would be always use a CAP or the attached syntax every time we want to apply a feature to a referenced object. That might work, but it falls among the impractical approaches to the problem ... it would break a very high percentage of existing EIffel code, not to mention cluttering things up quite a bit. +One way to make sure we comply with the target rule would be always use a CAP or the attached syntax every time we want to apply a feature to a referenced object. That might work, but it falls among the impractical approaches to the problem ... it would break a very high percentage of existing Eiffel code, not to mention cluttering things up quite a bit. ===Types as "attached" or "detachable"=== -Rather than trying to protect every feature call, Eiffel allows us to declare variables as being of '''attached types'''. This is an important extension to the Eiffel type system. +Rather than trying to protect every feature call, Eiffel allows us to declare any variable as being of an '''attached type'''. This is an important extension to the Eiffel type system. In Eiffel prior to the introduction of void-safe facilities, any reference variable could be set to Void. So, all variables were considered '"detachable"'. 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 new file mode 100644 index 00000000..4c69e16b --- /dev/null +++ b/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki @@ -0,0 +1,9 @@ +[[Property:title|Catalog of Certified Attachment Patterns]] +[[Property:link_title|What makes a Certified Attachment Pattern]] +[[Property:weight|8]] +[[Property:uuid|1a20197d-5a88-59c3-9a04-512399125661]] +{{underconstruction}} + + + +