Renamed current as trunk.

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

documentation/trunk/eiffel/Technical_papers/books-about-eiffel-method-and-language/ecma-standard-367.wiki

@@ -0,0 +1,16 @@
+[[Property:title|ECMA Standard 367]]
+[[Property:weight|1]]
+[[Property:uuid|b49b0949-85fa-31da-555e-003b09f6213e]]
+[[Image: ECMA-367 cover small|ECMA-367]]
+
+
+==ECMA Standard 367 -- Eiffel: Analysis, Design, and Programming Language==
+
+ECMA International
+
+Standard Eiffel syntax, validity, and semantics are described in this document, which is available [http://www.ecma-international.org/publications/standards/Ecma-367.htm online].
+
+ECMA-367 is a specification for the Eiffel programming language. Therefore, it can be useful as a reference, but it is definitely not a tutorial. That said, the document does contain occasional informative text and a general description chapter which can help readers understand the specification. 
+
+
+

documentation/trunk/eiffel/Technical_papers/books-about-eiffel-method-and-language/eiffel-language.wiki

@@ -0,0 +1,26 @@
+[[Property:title|Eiffel: The Language]]
+[[Property:weight|2]]
+[[Property:uuid|dae5a248-29f5-02b2-d01f-371394aa75e9]]
+[[Image: ETL]]
+
+
+=='''''Eiffel: The Language''''' by Bertrand Meyer.==
+
+Prentice Hall Object-Oriented Series.
+
+594 pp.
+
+Soft cover.
+
+<nowiki>ISBN 0-13-247925-7</nowiki>
+
+
+''Eiffel: The Language'' is one of the foundation volumes of Eiffel technology. It was originally published in 1992, and reprinted later with updates and corrections. 
+
+Because the language specification has changed since the last reprinting to incorporate new quality and productivity constructs, hardcopies of ''Eiffel: The Language'', although still available, will represent the bulk of Eiffel correctly, but will not reflect the latest important changes. 
+
+Currently ''Standard Eiffel'', the successor to ''Eiffel: The Language'', is a work-in-progress and is available in its current state online (See ''Standard Eiffel'', on [http://se.ethz.ch/~meyer/publications/#PSTE this page]). 
+
+The most current state of Eiffel syntax, validity, and semantics is described in the ISO/ECMA [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document], also available online.
+
+

documentation/trunk/eiffel/Technical_papers/books-about-eiffel-method-and-language/index.wiki

@@ -0,0 +1,6 @@
+[[Property:title|Books about the Eiffel Method and Language]]
+[[Property:link_title|Books]]
+[[Property:weight|5]]
+[[Property:uuid|721967da-6621-33f0-198f-9fc8ee26d37f]]
+
+

documentation/trunk/eiffel/Technical_papers/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki

@@ -0,0 +1,39 @@
+[[Property:title|Object-oriented Software Construction, 2nd Edition]]
+[[Property:link_title|OOSC2]]
+[[Property:weight|0]]
+[[Property:uuid|496983ef-b86e-772e-16b9-39b37ef80e37]]
+[[Image:OOSC2 small|OOSC2]]
+
+
+=='''''Object-Oriented Software Construction, 2nd Edition''''' by Bertrand Meyer.==
+
+Prentice Hall Professional Technical Reference.
+
+1254 + xxviii pp.
+
+Soft cover.
+
+<nowiki>ISBN 0-13-629155-4</nowiki>
+
+
+Click to [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554 buy from Amazon].
+
+
+This Jolt Award winner takes the reader through the clear, logical, and comprehensive formation of a method for object-oriented software development ... the Eiffel method. During this journey, the author evolves a notation capable of expressing the products of each phase of development, from analysis through implementation. This notation is the Eiffel programming language.
+
+
+==Praise for '''''Object-Oriented Software Construction, 2nd Edition'''''==
+
+Roger Smith, on the Dr. Dobbs Journal website, writes:
+
+:"In my unbiased opinion [...] it is destined to become the comprehensive and definitive reference for most methodological and technical questions raised by object technology. Its width and breadth of scope is impressive, from object-oriented techniques like Design by Contract and inheritance, to methodology issues like patterns and class design, to advanced issues like concurrency and persistence."
+
+
+In ''Unix Review'', Stan Kelly-Bootle calls this book "The ultimate O-O guide."
+
+
+Ian Graham, in ''Journal of Object-Oriented Programming'' calls it "Epoch-making".
+
+
+
+

documentation/trunk/eiffel/Technical_papers/books-about-eiffel-method-and-language/touch-class-learning-program-well-objects-and-contracts.wiki

@@ -0,0 +1,35 @@
+[[Property:title|Touch of Class: Learning to Program Well with Objects and Contracts]]
+[[Property:weight|-1]]
+[[Property:uuid|3b4afd2f-6433-c619-f9a4-602c430c6902]]
+[[Image:Touch of Class cover small]]
+
+
+
+=='''''Touch of Class: Learning to Program Well with Objects and Contracts''''' by Bertrand Meyer==
+
+Springer-Verlag, 2009
+
+876 + lxiv pp.
+
+<nowiki>ISBN-13: 978-3540921448 </nowiki>
+
+Full color printing; many color illustrations and photographs
+
+
+Click to [http://www.amazon.com/Touch-Class-Learning-Program-Contracts/dp/3540921443 buy from Amazon].
+
+
+Is this really a book about Eiffel? Perhaps in some senses it is not. It is a book about exactly what the subtitle indicates: ''Learning to Program Well with Objects and Contracts.'' (Primary emphasis should fall on the word "''Well''".) 
+
+Still, the Eiffel method and language are used in this journey as tools, the best tools known, to help those seeking excellence in software development become prepared to meet the types of challenges a career in software will present.  In the rapidly changing software world, this is a tall order. As the preface (for instructors) states: 
+
+:'' It is not enough to present immediately applicable technology, for which in our globalized industry a cheaper programmer will always be available somewhere ... [Software professionals] must master software development as a professional endeavor, and by this distinguish themselves from the masses of occasional or amateur programmers.''
+
+
+''Touch of Class'' imparts its message using techniques which have accumulated through decades of study of technical learning and have been applied for several years in courses at ETH Zurich. These techniques include the extensive study and reuse of libraries of high-quality software components, employment of the Eiffel object-oriented method and Design by Contract, an introduction to formal methods and a ubiquitous awareness for software engineering concerns. 
+
+A unique and refreshing aspect of ''Touch of Class'' is seen throughout the volume. Credit is given for ideas which form the foundation of modern software thinking, and in the process, those pioneers upon whose shoulders all software professionals stand, are made human and personal by photographs and historical vignettes. 
+
+
+
+

documentation/trunk/eiffel/Technical_papers/eiffel-expression-language.wiki

@@ -0,0 +1,16 @@
+[[Property:title|Eiffel as an expression language]]
+[[Property:weight|0]]
+[[Property:uuid|61e93102-c558-42e7-7784-0b60b9257b5d]]
+A functional-programming style, or more generally a style involving more expressions and fewer instructions, is possible in Eiffel. In particular, the agent mechanism embeds a full functional-programming mechanism in the object-oriented framework of the language.
+
+To make the notations simpler, a number of extensions have been proposed. They involve no fundamental new language mechanisms, but provide new, more concise notations for existing mechanisms. Examples are:
+*Conditional expressions
+*Implicit tuple, a rule allowing the omission of brackets for an actual argument when it is a tuple and the last argument, e.g. f (a, b, c) as an abbreviation for f ([a, b, c]) (an example involving just one argument). Tuples already provided the equivalent of a variable-argument ("varargs") facility, but it is made simpler to use with this convention.
+*Parenthesis alias, making it possible to write just f (x, y) when f is an agent (closure, lambda expression, delegate etc. in other terminologies), i.e. treating f as if it were a function; the notation is simply an abbreviation for f.item ([x, y]) (this example also takes advantage of implicit tuples). It has many other applications since a "parenthesis alias" can be defined for a feature of any class.
+*Avoiding explicit assignments to '''Result'''.
+*Type inference (to avoid explicitly specifying the type when it can be deduced from the context). This is a facility for the programmer, useful in particular for local variables, but does not affect the type system: Eiffel remains strongly typed, it is just that you can be lazy about writing the type when there is no ambiguity.
+*In the same vein, omitting the entire list of generic parameters when it can be inferred.
+
+The description of the mechanism (see the link below) is in the form of a set of slides explaining the concepts and presenting example. This is a working document and feedback is welcome.
+
+

documentation/trunk/eiffel/Technical_papers/index.wiki

@@ -0,0 +1,9 @@
+[[Property:title|Technical papers about Eiffel]]
+[[Property:description|Background, foundation, or supplemental information about uncovered topics]]
+[[Property:link_title|Papers]]
+[[Property:weight|4]]
+[[Property:uuid|d2b880d6-d1dc-9811-32b8-ed718ad4d4be]]
+Occasionally papers are produced providing background, foundation, or supplemental information about the topics covered by the Eiffel documentation. Although the material in these papers might be of interest to many Eiffel users, they might not be suitable in their current form for inclusion in the mainstream documentation books. 
+
+You will find a collection of these papers in this book.
+

documentation/trunk/eiffel/Technical_papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki

@@ -0,0 +1,25 @@
+[[Property:title|Void-safety: how Eiffel removes null-pointer dereferencing]]
+[[Property:weight|0]]
+[[Property:uuid|d9380464-4312-b76e-9bfd-e57df0f59b4a]]
+This white paper (see [[file:void-safe-eiffel.pdf|document as pdf]]) presents the Eiffel void-safety mechanism, fully implemented in EiffelStudio 6.4.
+
+In almost every program running today there is a ticking time bomb: the risk of a "void call". A void call is possible in programs written in almost any programming language; its effect is usually to crash the program. Many unexplained program failures and other abnormal behaviors result from void calls.
+
+While  extensive testing can decrease the likelihood of a void call, it cannot  remove the possibility.  The solution has to come from the programming  language.
+<!--break-->
+Professor C.A.R. Hoare from Microsoft Research, winner of the Turing Award and the Kyoto Prize, calls the presence of void calls  in modern programming languages the "billion-dollar mistake":
+
+:"The invention of the null reference in 1965" [the source of void calls] "has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
+
+(Citation at:  [http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake] )
+
+
+The Eiffel solution relies on a combination of language mechanisms:
+
+*"Certified Attachment Patterns" are code schemes that the  EiffelStudio compiler guarantees to be void-safe.
+*"Attached types" are types that are guaranteed to have  non-void values.
+*The "Object Test" instruction lets programmers treat  void values in a special way.
+
+
+The White Paper (see the link below) describes the theoretical and practical challenges of ensuring void-safety and presents the Eiffel mechanism.
+