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

Author:halw

Browse Source 
Date:2009-05-14T21:10:00.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@216 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-05-14 21:10:00 +00:00
parent 7aa2ee9e67
commit b18408615e
3 changed files with 14 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/method/void-safe-programming-eiffel/index.wiki
View File

@@ -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.

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

@@ -95,17 +95,17 @@ By using the '''attached syntax''', we can perform an '''object test''' on a var
l_x.f (a)
end
</code>
In the example above, <code>x</code> is tested to make certain that it is attached. If so, the local <code>l_x</code> is created and can be used safely even if <code>x</code> 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, <code>x</code> is tested to make certain that it is attached. If so, the local <code>l_x</code> is attached to the same object as <code>x</code> and can be used safely even if <code>x</code> 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 <code>Void</code>. So, all variables were considered '"detachable"'.

9
documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki Normal file
View File

@@ -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}}