mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2026-04-04 17:19:23 +02:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2008-10-15T22:26:20.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@83 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2008-10-15 22:41:53 +00:00
parent a7cbdda131
commit 3e5e123581
3 changed files with 133 additions and 95 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki
View File

@@ -56,13 +56,15 @@ The name of the class is <code> HELLO </code>. Any class may contain "features";
The definition of <code> make </code> appears in a <code> feature </code> clause. There may be any number of such clauses (to separate features into logical categories), and each may contain any number of feature declarations. Here we have only one.
The line starting with <code> -- </code> (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the feature is named. As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation.
The line starting with <code> -- </code> (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the point at which the feature is named. As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation.
The body of the feature is introduced by the <code> do </code> keyword and terminated by <code> end </code>. It consists of two output instructions. They both use <code> io </code>, a generally available reference to an object that provides access to standard input and output mechanisms; the notation <code> io </code> . <code> f </code>, for some feature <code> f </code> of the corresponding library class ( <code> STD_FILES </code>), means "apply <code> f </code> to <code> io </code>". Here we use two such features:
The body of the feature is introduced by the <code> do </code> keyword and terminated by <code> end </code>. It consists of two output instructions. They both use <code> io </code>, a generally available reference to an object that provides access to standard input and output mechanisms; the notation<code> io.f</code>, for some feature<code> f</code> of the corresponding library class ( <code> STD_FILES </code>, in this case), means "apply<code> f</code> to<code> io</code>". Here we use two such features:
* <code> put_string </code> outputs a string, passed as argument, here <code> "Hello World" </code>.
* <code> put_new_line </code> terminates the line.
Rather than using a call to <code> put_new_line </code>, the first version of the class simply includes a new-line character, denoted as <code> %N </code>, at the end of the string. Either technique is acceptable.
Rather than using a call to <code> put_new_line </code>, the first version of the class simply includes a new-line character, denoted as<code> %N </code>, at the end of the string. Either technique is acceptable.
You may have noticed another difference between the two versions. The first version uses a call to <code>print</code> where the second uses <code>io.put_string</code> . Here too, the effect is identical and either technique is acceptable. In the next section, you will begin to see how things like <code>io</code> and <code>print</code> become available for use in a class like <code>HELLO</code>.
To build the system and execute it:
* Start EiffelStudio