Author:halw

Date:2009-09-18T18:49:11.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@302 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/method/_images/Catcall_demo_class_diagram.png.data

@@ -0,0 +1,3 @@
+title=Catcall example class diagram
+author=halw
+path=content/catcall-example-class-diagram

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

@@ -52,14 +52,20 @@ As of EiffelStudio version 6.4, the majority of the libraries distributed with E
 
 {{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. }}
 
-==Using non-void-safe libraries==
 
 ==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.
 
+
 ==More about the ''attached syntax''==
 
+The complete attached syntax is:
+<code>
+		attached {SOME_CLASS} exp as l_exp
+</code>
+In this section, we will see more ways in which to use this versatile language facility.
+
 ===As a CAP which yields a local variable===
 
 In the introduction to the attached syntax, we used an example which showed how the attached syntax is directly relevant to void-safety. That is, the code: 

documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki

@@ -39,7 +39,22 @@ The Eiffel standard (2nd edition, June 2006) defines a CAP as follows:
 
 The terminology used in the definition is precise. For example, terms like "read-only entity" and "scope of a void test" have specific meanings that are supported by their own definitions in the standard. 
 
-Here we will consider the CAP definition only, but our discussion will be supported by the ancillary definitions. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you need to review the specific details.
+The discussion here will be less formal (and less precise) than that in the standard, and is intended to be a practical guide. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you wish to follow the specifics.
+
+
+==CAP-able expressions==
+
+In the first context, the definition states that the expression <code>exp</code> can be an '''Object-Test Local'''. An Object-Test Local is the identifier specified for a fresh local entity in an '''object test'''. Remember, object tests are coded using the '''attached syntax'''. 
+<code>
+            attached x as l_x 
+</code>
+In the object test expression above, the identifier <code>l_x</code> is an Object-Test Local.
+
+In the second context, the expression can be a read-only entity. Read-only entities are:
+# Constant attributes
+# formal arguments
+# Object-Test Locals
+# <code>Current</code>