Author:halw

Date:2008-10-14T22:21:18.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@82 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2008-10-14 22:21:18 +00:00
parent 7bf0b00d90
commit a7cbdda131

View File

@@ -14,7 +14,7 @@ create
feature feature
make is make
do do
print ("Hello World%N") print ("Hello World%N")
end end
@@ -36,7 +36,7 @@ create
feature feature
make is make
-- Print a simple message. -- Print a simple message.
do do
io.put_string ("Hello World") io.put_string ("Hello World")
@@ -56,7 +56,7 @@ 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 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 <code> is </code>. As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions|"The contract form of a class", page 44]] , 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 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 </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:
* <code> put_string </code> outputs a string, passed as argument, here <code> "Hello World" </code>. * <code> put_string </code> outputs a string, passed as argument, here <code> "Hello World" </code>.