Eiffel (programming language)

Last updated
Eiffel
Eiffel logo.svg
Paradigm Object-oriented, Class-based, Generic, Concurrent
Designed by Bertrand Meyer
Developer Eiffel Software
First appeared1986 [1]
Stable release
EiffelStudio 23.09 [2] / 6 October 2023;3 months ago (2023-10-06)
Typing discipline static
Implementation languageEiffel
Platform Cross-platform
OS FreeBSD, Linux, macOS, OpenBSD, Solaris, Windows
License dual and enterprise
Filename extensions .e
Website eiffel.org
Major implementations
EiffelStudio, LibertyEiffel, SmartEiffel, Visual Eiffel, Gobo Eiffel, "The Eiffel Compiler" tecomp
Influenced by
Ada, Simula, Z
Influenced
Ada 2012, Albatross, C#, D, Java, Racket, Ruby, [3] Sather, Scala

Eiffel is an object-oriented programming language designed by Bertrand Meyer (an object-orientation proponent and author of Object-Oriented Software Construction ) and Eiffel Software. Meyer conceived the language in 1985 with the goal of increasing the reliability of commercial software development; [4] the first version becoming available in 1986. In 2005, Eiffel became an ISO-standardized language.

Contents

The design of the language is closely connected with the Eiffel programming method. Both are based on a set of principles, including design by contract, command–query separation, the uniform-access principle, the single-choice principle, the open–closed principle, and option–operand separation.

Many concepts initially introduced by Eiffel later found their way into Java, C#, and other languages. [5] New language design ideas, particularly through the Ecma/ISO standardization process, continue to be incorporated into the Eiffel language.

Characteristics

The key characteristics of the Eiffel language include:

Design goals

Eiffel emphasizes declarative statements over procedural code and attempts to eliminate the need for bookkeeping instructions.

Eiffel shuns coding tricks or coding techniques intended as optimization hints to the compiler. The aim is not only to make the code more readable, but also to allow programmers to concentrate on the important aspects of a program without getting bogged down in implementation details. Eiffel's simplicity is intended to promote simple, extensible, reusable, and reliable answers to computing problems. Compilers for computer programs written in Eiffel provide extensive optimization techniques, such as automatic in-lining, that relieve the programmer of part of the optimization burden.

Background

Eiffel was originally developed by Eiffel Software, a company founded by Bertrand Meyer. Object-Oriented Software Construction contains a detailed treatment of the concepts and theory of the object technology that led to Eiffel's design. [9]

The design goal behind the Eiffel language, libraries, and programming methods is to enable programmers to create reliable, reusable software modules. Eiffel supports multiple inheritance, genericity, polymorphism, encapsulation, type-safe conversions, and parameter covariance. Eiffel's most important contribution to software engineering is design by contract (DbC), in which assertions, preconditions, postconditions, and class invariants are employed to help ensure program correctness without sacrificing efficiency.

Eiffel's design is based on object-oriented programming theory, with only minor influence of other paradigms or concern for support of legacy code. Eiffel formally supports abstract data types. Under Eiffel's design, a software text should be able to reproduce its design documentation from the text itself, using a formalized implementation of the "Abstract Data Type".

Implementations and environments

EiffelStudio is an integrated development environment available under either an open source or a commercial license. It offers an object-oriented environment for software engineering. EiffelEnvision is a plug-in for Microsoft Visual Studio that allows users to edit, compile, and debug Eiffel projects from within the Microsoft Visual Studio IDE. Five other open source implementations are available: "The Eiffel Compiler" tecomp; Gobo Eiffel; SmartEiffel, the GNU implementation, based on an older version of the language; LibertyEiffel, based on the SmartEiffel compiler; and Visual Eiffel.

Several other programming languages incorporate elements first introduced in Eiffel. Sather, for example, was originally based on Eiffel but has since diverged, and now includes several functional programming features. The interactive-teaching language Blue, forerunner of BlueJ, is also Eiffel-based. The Apple Media Tool includes an Eiffel-based Apple Media Language.

Specifications and standards

The Eiffel language definition is an international standard of the ISO. The standard was developed by ECMA International, which first approved the standard on 21 June 2005 as Standard ECMA-367, Eiffel: Analysis, Design and Programming Language. In June 2006, ECMA and ISO adopted the second version. In November 2006, ISO first published that version. The standard can be found and used free of charge on the ECMA site. [10] The ISO version [11] is identical in all respects except formatting.

Eiffel Software, "The Eiffel Compiler" tecomp and Eiffel-library-developer Gobo have committed to implementing the standard; Eiffel Software's EiffelStudio 6.1 and "The Eiffel Compiler" tecomp implement some of the major new mechanisms—in particular, inline agents, assigner commands, bracket notation, non-conforming inheritance, and attached types. The SmartEiffel team has turned away from this standard to create its own version of the language, which they believe to be closer to the original style of Eiffel. Object Tools has not disclosed whether future versions of its Eiffel compiler will comply with the standard. LibertyEiffel implements a dialect somewhere in between the SmartEiffel language and the standard.

The standard cites the following, predecessor Eiffel-language specifications:

The current version of the standard from June 2006 contains some inconsistencies (e.g. covariant redefinitions)[ citation needed ]. The ECMA committee has not yet announced any timeline and direction on how to resolve the inconsistencies.

Syntax and semantics

Overall structure

An Eiffel "system" or "program" is a collection of classes. Above the level of classes, Eiffel defines cluster, which is essentially a group of classes, and possibly of subclusters (nested clusters). Clusters are not a syntactic language construct, but rather a standard organizational convention. Typically an Eiffel program will be organized with each class in a separate file, and each cluster in a directory containing class files. In this organization, subclusters are subdirectories. For example, under standard organizational and casing conventions, x.e might be the name of a file that defines a class called X.

A class contains features, which are similar to "routines", "members", "attributes" or "methods" in other object-oriented programming languages. A class also defines its invariants, and contains other properties, such as a "notes" section for documentation and metadata. Eiffel's standard data types, such as INTEGER, STRING and ARRAY, are all themselves classes.

Every system must have a class designated as "root", with one of its creation procedures designated as "root procedure". Executing a system consists of creating an instance of the root class and executing its root procedure. Generally, doing so creates new objects, calls new features, and so on.

Eiffel has five basic executable instructions: assignment, object creation, routine call, condition, and iteration. Eiffel's control structures are strict in enforcing structured programming: every block has exactly one entry and exactly one exit.

Scoping

Unlike many object-oriented languages, but like Smalltalk, Eiffel does not permit any assignment into attributes of objects, except within the features of an object, which is the practical application of the principle of information hiding or data abstraction, requiring formal interfaces for data mutation. To put it in the language of other object-oriented programming languages, all Eiffel attributes are "protected", and "setters" are needed for client objects to modify values. An upshot of this is that "setters" can and normally do, implement the invariants for which Eiffel provides syntax.

While Eiffel does not allow direct access to the features of a class by a client of the class, it does allow for the definition of an "assigner command", such as:

some_attribute:SOME_TYPEassignset_some_attributeset_some_attribute(v:VALUE_TYPE)-- Set value of some_attribute to `v'.dosome_attribute:=vend

While a slight bow to the overall developer community to allow something looking like direct access (e.g. thereby breaking the Information Hiding Principle), the practice is dangerous as it hides or obfuscates the reality of a "setter" being used. In practice, it is better to redirect the call to a setter rather than implying a direct access to a feature like some_attribute as in the example code above.[ citation needed ]

Unlike other languages, having notions of "public", "protected", "private" and so on, Eiffel uses an exporting technology to more precisely control the scoping between client and supplier classes. Feature visibility is checked statically at compile-time. For example, (below), the "{NONE}" is similar to "protected" in other languages. Scope applied this way to a "feature set" (e.g. everything below the 'feature' keyword to either the next feature set keyword or the end of the class) can be changed in descendant classes using the "export" keyword.

feature{NONE}-- Initializationdefault_create-- Initialize a new `zero' decimal instance.domake_zeroend

Alternatively, the lack of a {x} export declaration implies {ANY} and is similar to the "public" scoping of other languages.

feature-- Constants

Finally, scoping can be selectively and precisely controlled to any class in the Eiffel project universe, such as:

feature{DECIMAL,DCM_MA_DECIMAL_PARSER,DCM_MA_DECIMAL_HANDLER}-- Access

Here, the compiler will allow only the classes listed between the curly braces to access the features within the feature group (e.g. DECIMAL, DCM_MA_DECIMAL_PARSER, DCM_MA_DECIMAL_HANDLER).

"Hello, world!"

A programming language's look and feel is often conveyed using a "Hello, world!" program. Such a program written in Eiffel might be:

classHELLO_WORLDcreatemakefeaturemakedoprint("Hello, world!%N")endend

This program contains the class HELLO_WORLD. The constructor (create routine) for the class, named make, invokes the print system library routine to write a "Hello, world!" message to the output.

Design by contract

The concept of Design by Contract is central to Eiffel. The contracts assert what must be true before a routine is executed (precondition) and what must hold to be true after the routine finishes (post-condition). Class Invariant contracts define what assertions must hold true both before and after any feature of a class is accessed (both routines and attributes). Moreover, contracts codify into executable code developer and designers assumptions about the operating environment of the features of a class or the class as a whole by means of the invariant.

The Eiffel compiler is designed to include the feature and class contracts in various levels. EiffelStudio, for example, executes all feature and class contracts during execution in the "Workbench mode." When an executable is created, the compiler is instructed by way of the project settings file (e.g. ECF file) to either include or exclude any set of contracts. Thus, an executable file can be compiled to either include or exclude any level of contract, thereby bringing along continuous levels of unit and integration testing. Moreover, contracts can be continually and methodically exercised by way of the Auto-Test feature found in EiffelStudio.

The Design by Contract mechanisms are tightly integrated with the language and guide redefinition of features in inheritance:

In addition, the language supports a "check instruction" (a kind of "assert"), loop invariants, and loop variants (which guarantee loop termination).

Void-safe capability

Void-safe capability, like static typing, is another facility for improving software quality. Void-safe software is protected from run time errors caused by calls to void references, and therefore will be more reliable than software in which calls to void targets can occur. The analogy to static typing is a useful one. In fact, void-safe capability could be seen as an extension to the type system, or a step beyond static typing, because the mechanism for ensuring void safety is integrated into the type system.

The guard against void target calls can be seen by way of the notion of attachment and (by extension) detachment (e.g. detachable keyword). The void-safe facility can be seen in a short re-work of the example code used above:

some_attribute:detachableSOME_TYPEuse_some_attribute-- Set value of some_attribute to `v'.doifattachedsome_attributeasl_attributethendo_something(l_attribute)endenddo_something(a_value:SOME_TYPE)-- Do something with `a_value'.do...doingsomethingwith`a_value'...end

The code example above shows how the compiler can statically address the reliability of whether some_attribute will be attached or detached at the point it is used. Notably, the attached keyword allows for an "attachment local" (e.g. l_attribute), which is scoped to only the block of code enclosed by the if-statement construct. Thus, within this small block of code, the local variable (e.g. l_attribute) can be statically guaranteed to be non-void (i.e. void safe).

Features: commands and queries

The primary characteristic of a class is that it defines a set of features: as a class represents a set of run-time objects, or "instances", a feature is an operation on these objects. There are two kinds of features: queries and commands. A query provides information about an instance. A command modifies an instance.

The command-query distinction is important to the Eiffel method. In particular:

Overloading

Eiffel does not allow argument overloading. Each feature name within a class always maps to a specific feature within the class. One name, within one class, means one thing. This design choice helps the readability of classes, by avoiding a cause of ambiguity about which routine will be invoked by a call. It also simplifies the language mechanism; in particular, this is what makes Eiffel's multiple inheritance mechanism possible. [12]

Names can, of course, be reused in different classes. For example, the feature plus (along with its infix alias "+") is defined in several classes: INTEGER, REAL, STRING, etc.

Genericity

A generic class is a class that varies by type (e.g. LIST [PHONE], a list of phone numbers; ACCOUNT [G->ACCOUNT_TYPE], allowing for ACCOUNT [SAVINGS] and ACCOUNT [CHECKING], etc.). Classes can be generic, to express that they are parameterized by types. Generic parameters appear in square brackets:

classLIST[G]...

G is known as a "formal generic parameter". (Eiffel reserves "argument" for routines, and uses "parameter" only for generic classes.) With such a declaration G represents within the class an arbitrary type; so a function can return a value of type G, and a routine can take an argument of that type:

item:Gdo...endput(x:G)do...end

The LIST [INTEGER] and LIST [WORD] are "generic derivations" of this class. Permitted combinations (with n: INTEGER, w: WORD, il: LIST [INTEGER], wl: LIST [WORD]) are:

n:=il.itemwl.put(w)

INTEGER and WORD are the "actual generic parameters" in these generic derivations.

It is also possible to have 'constrained' formal parameters, for which the actual parameter must inherit from a given class, the "constraint". For example, in

classHASH_TABLE[G,KEY->HASHABLE]

a derivation HASH_TABLE [INTEGER, STRING] is valid only if STRING inherits from HASHABLE (as it indeed does in typical Eiffel libraries). Within the class, having KEY constrained by HASHABLE means that for x: KEY it is possible to apply to x all the features of HASHABLE, as in x.hash_code.

Inheritance basics

To inherit from one or more others, a class will include an inherit clause at the beginning:

classCinheritAB-- ... Rest of class declaration ...

The class may redefine (override) some or all of the inherited features. This must be explicitly announced at the beginning of the class through a redefine subclause of the inheritance clause, as in

classCinheritAredefinef,g,hendBredefineu,vend

See [13] for a complete discussion of Eiffel inheritance.

Deferred classes and features

Classes may be defined with deferred class rather than with class to indicate that the class may not be directly instantiated. Non-instantiatable classes are called abstract classes in some other object-oriented programming languages. In Eiffel parlance, only an "effective" class can be instantiated (it may be a descendant of a deferred class). A feature can also be deferred by using the deferred keyword in place of a do clause. If a class has any deferred features it must be declared as deferred; however, a class with no deferred features may nonetheless itself be deferred.

Deferred classes play some of the same role as interfaces in languages such as Java, though many object-oriented programming theorists believe interfaces are themselves largely an answer to Java's lack of multiple inheritance (which Eiffel has). [14] [15]

Renaming

A class that inherits from one or more others gets all its features, by default under their original names. It may, however, change their names through rename clauses. This is required in the case of multiple inheritance if there are name clashes between inherited features; without renaming, the resulting class would violate the no-overloading principle noted above and hence would be invalid.

Tuples

Tuples types may be viewed as a simple form of class, providing only attributes and the corresponding "setter" procedure. A typical tuple type reads

TUPLE[name:STRING;weight:REAL;date:DATE]

and could be used to describe a simple notion of birth record if a class is not needed. An instance of such a tuple is simply a sequence of values with the given types, given in brackets, such as

["Brigitte",3.5,Last_night]

Components of such a tuple can be accessed as if the tuple tags were attributes of a class, for example if t has been assigned the above tuple then t.weight has value 3.5.

Thanks to the notion of assigner command (see below), dot notation can also be used to assign components of such a tuple, as in

t.weight:=t.weight+0.5

The tuple tags are optional, so that it is also possible to write a tuple type as TUPLE [STRING, REAL, DATE]. (In some compilers this is the only form of tuple, as tags were introduced with the ECMA standard.)

The precise specification of e.g. TUPLE [A, B, C] is that it describes sequences of at least three elements, the first three being of types A, B, C respectively. As a result, TUPLE [A, B, C] conforms to (may be assigned to) TUPLE [A, B], to TUPLE [A] and to TUPLE (without parameters), the topmost tuple type to which all tuple types conform.

Agents

Eiffel's "agent" mechanism wraps operations into objects. This mechanism can be used for iteration, event-driven programming, and other contexts in which it is useful to pass operations around the program structure. Other programming languages, especially ones that emphasize functional programming, allow a similar pattern using continuations, closures, or generators; Eiffel's agents emphasize the language's object-oriented paradigm, and use a syntax and semantics similar to code blocks in Smalltalk and Ruby.

For example, to execute the my_action block for each element of my_list, one would write:

my_list.do_all(agentmy_action)

To execute my_action only on elements satisfying my_condition, a limitation/filter can be added:

my_list.do_if(agentmy_action,agentmy_condition)

In these examples, my_action and my_condition are routines. Prefixing them with agent yields an object that represents the corresponding routine with all its properties, in particular the ability to be called with the appropriate arguments. So if a represents that object (for example because a is the argument to do_all), the instruction

a.call([x])

will call the original routine with the argument x, as if we had directly called the original routine: my_action (x). Arguments to call are passed as a tuple, here [x].

It is possible to keep some arguments to an agent open and make others closed. The open arguments are passed as arguments to call: they are provided at the time of agent use. The closed arguments are provided at the time of agent definition. For example, if action2 has two arguments, the iteration

my_list.do_all(agentaction2(?,y))

iterates action2 (x, y) for successive values of x, where the second argument remains set to y. The question mark ? indicates an open argument; y is a closed argument of the agent. Note that the basic syntax agent f is a shorthand for agent f (?, ?, ...) with all arguments open. It is also possible to make the target of an agent open through the notation {T}? where T is the type of the target.

The distinction between open and closed operands (operands = arguments + target) corresponds to the distinction between bound and free variables in lambda calculus. An agent expression such as action2 (?, y) with some operands closed and some open corresponds to a version of the original operation curried on the closed operands.

The agent mechanism also allows defining an agent without reference to an existing routine (such as my_action, my_condition, action2), through inline agents as in

my_list.do_all(agent(s:STRING)requirenot_void:s/=Voiddos.append_character(',')ensureappended:s.count=olds.count+1end)

The inline agent passed here can have all the trappings of a normal routine, including precondition, postcondition, rescue clause (not used here), and a full signature. This avoids defining routines when all that's needed is a computation to be wrapped in an agent. This is useful in particular for contracts, as in an invariant clause that expresses that all elements of a list are positive:

my_list.for_all(agent(x:INTEGER):BOOLEANdoResult:=(x>0)end)

The current agent mechanism leaves a possibility of run-time type error (if a routine with n arguments is passed to an agent expecting m arguments with m < n). This can be avoided by a run-time check through the precondition valid_arguments of call. Several proposals for a purely static correction of this problem are available, including a language change proposal by Ribet et al. [16]

Once routines

A routine's result can be cached using the once keyword in place of do. Non-first calls to a routine require no additional computation or resource allocation, but simply return a previously computed result. A common pattern for "once functions" is to provide shared objects; the first call will create the object, subsequent ones will return the reference to that object. The typical scheme is:

shared_object:SOME_TYPEoncecreateResult.make(args)-- This creates the object and returns a reference to it through `Result'.end

The returned object—Result in the example—can itself be mutable, but its reference remains the same.

Often "once routines" perform a required initialization: multiple calls to a library can include a call to the initialization procedure, but only the first such call will perform the required actions. Using this pattern initialization can be decentralized, avoiding the need for a special initialization module. "Once routines" are similar in purpose and effect to the singleton pattern in many programming languages, and to the Borg pattern used in Python.

By default, a "once routine" is called once per thread. The semantics can be adjusted to once per process or once per object by qualifying it with a "once key", e.g. once ("PROCESS").

Conversions

Eiffel provides a mechanism to allow conversions between various types. The mechanisms coexists with inheritance and complements it. To avoid any confusion between the two mechanisms, the design enforces the following principle:

(Conversion principle) A type may not both conform and convert to another.

For example, NEWSPAPER may conform to PUBLICATION, but INTEGER converts to REAL (and does not inherit from it).

The conversion mechanism simply generalizes the ad hoc conversion rules (such as indeed between INTEGER and REAL) that exist in most programming languages, making them applicable to any type as long as the above principle is observed. For example, a DATE class may be declared to convert to STRING; this makes it possible to create a string from a date simply through

my_string:=my_date

as a shortcut for using an explicit object creation with a conversion procedure:

createmy_string.make_from_date(my_date)

To make the first form possible as a synonym for the second, it suffices to list the creation procedure (constructor) make_from_date in a convert clause at the beginning of the class.

As another example, if there is such a conversion procedure listed from TUPLE [day: INTEGER; month: STRING; year: INTEGER], then one can directly assign a tuple to a date, causing the appropriate conversion, as in

Bastille_day:=[14,"July",1789]

Exception handling

Exception handling in Eiffel is based on the principles of design by contract. For example, an exception occurs when a routine's caller fails to satisfy a precondition, or when a routine cannot ensure a promised postcondition. In Eiffel, exception handling is not used for control flow or to correct data-input mistakes.

An Eiffel exception handler is defined using the rescue keyword. Within the rescue section, the retry keyword executes the routine again. For example, the following routine tracks the number of attempts at executing the routine, and only retries a certain number of times:

connect_to_server(server:SOCKET)-- Connect to a server or give up after 10 attempts.requireserver/=Voidandthenserver.address/=Voidlocalattempts:INTEGERdoserver.connectensureconnected:server.is_connectedrescueifattempts<10thenattempts:=attempts+1retryendend

This example is arguably flawed for anything but the simplest programs, however, because connection failure is to be expected. For most programs a routine name like attempt_connecting_to_server would be better, and the postcondition would not promise a connection, leaving it up to the caller to take appropriate steps if the connection was not opened.

Concurrency

A number of networking and threading libraries are available, such as EiffelNet and EiffelThreads. A concurrency model for Eiffel, based on the concepts of design by contract, is SCOOP, or Simple Concurrent Object-Oriented Programming, not yet part of the official language definition but available in EiffelStudio. CAMEO [17] is an (unimplemented) variation of SCOOP for Eiffel. Concurrency also interacts with exceptions. Asynchronous exceptions can be troublesome (where a routine raises an exception after its caller has itself finished). [18]

Operator and bracket syntax, assigner commands

Eiffel's view of computation is completely object-oriented in the sense that every operation is relative to an object, the "target". So for example an addition such as

a+b

is conceptually understood as if it were the method call

a.plus(b)

with target a, feature plus and argument b.

Of course, the former is the conventional syntax and usually preferred. Operator syntax makes it possible to use either form by declaring the feature (for example in INTEGER, but this applies to other basic classes and can be used in any other for which such an operator is appropriate):

plusalias"+"(other:INTEGER):INTEGER-- ... Normal function declaration...end

The range of operators that can be used as "alias" is quite broad; they include predefined operators such as "+" but also "free operators" made of non-alphanumeric symbols. This makes it possible to design special infix and prefix notations, for example in mathematics and physics applications.

Every class may in addition have one function aliased to "[]", the "bracket" operator, allowing the notation a [i, ...] as a synonym for a.f (i, ...) where f is the chosen function. This is particularly useful for container structures such as arrays, hash tables, lists etc. For example, access to an element of a hash table with string keys can be written

number:=phone_book["JILL SMITH"]

"Assigner commands" are a companion mechanism designed in the same spirit of allowing well-established, convenient notation reinterpreted in the framework of object-oriented programming. Assigner commands allow assignment-like syntax to call "setter" procedures. An assignment proper can never be of the form a.x := v as this violates information hiding; you have to go for a setter command (procedure). For example, the hash table class can have the function and the procedure

itemalias"[]"(key:STRING):ELEMENT[3]-- The element of key `key'.-- ("Getter" query)do...endput(e:ELEMENT;key:STRING)-- Insert the element `e', associating it with the key `key'.-- ("Setter" command)do...end

Then to insert an element you have to use an explicit call to the setter command:

[4]phone_book.put(New_person,"JILL SMITH")

It is possible to write this equivalently as

[5]phone_book["JILL SMITH"]:=New_person

(in the same way that phone_book ["JILL SMITH"] is a synonym for number := phone_book.item ("JILL SMITH")), provided the declaration of item now starts (replacement for [3]) with

itemalias"[]"(key:STRING):ELEMENTassignput

This declares put as the assigner command associated with item and, combined with the bracket alias, makes [5] legal and equivalent to [4]. (It could also be written, without taking advantage of the bracket, as phone_book.item ("JILL SMITH") := New_person.

Note: The argument list of a's assigner is constrained to be: (a's return type;all of a's argument list...)

Lexical and syntax properties

Eiffel is not case-sensitive. The tokens make, maKe and MAKE all denote the same identifier. See, however, the "style rules" below.

Comments are introduced by -- (two consecutive dashes) and extend to the end of the line.

The semicolon, as instruction separator, is optional. Most of the time the semicolon is just omitted, except to separate multiple instructions on a line. This results in less clutter on the program page.

There is no nesting of feature and class declarations. As a result, the structure of an Eiffel class is simple: some class-level clauses (inheritance, invariant) and a succession of feature declarations, all at the same level.

It is customary to group features into separate "feature clauses" for more readability, with a standard set of basic feature tags appearing in a standard order, for example:

classHASH_TABLE[ELEMENT,KEY->HASHABLE]inheritTABLE[ELEMENT]feature-- Initialization-- ... Declarations of initialization commands (creation procedures/constructors) ...feature-- Access-- ... Declarations of non-boolean queries on the object state, e.g. item ...feature-- Status report-- ... Declarations of boolean queries on the object state, e.g. is_empty ...feature-- Element change-- ... Declarations of commands that change the structure, e.g. put ...-- etc.end

In contrast to most curly bracket programming languages, Eiffel makes a clear distinction between expressions and instructions. This is in line with the Command-Query Separation principle of the Eiffel method.

Style conventions

Much of the documentation of Eiffel uses distinctive style conventions, designed to enforce a consistent look-and-feel. Some of these conventions apply to the code format itself, and others to the standard typographic rendering of Eiffel code in formats and publications where these conventions are possible.

While the language is case-insensitive, the style standards prescribe the use of all-capitals for class names (LIST), all-lower-case for feature names (make), and initial capitals for constants (Avogadro). The recommended style also suggests underscore to separate components of a multi-word identifier, as in average_temperature.

The specification of Eiffel includes guidelines for displaying software texts in typeset formats: keywords in bold, user-defined identifiers and constants are shown in italics, comments, operators, and punctuation marks in Roman, with program text in blue as in the present article to distinguish it from explanatory text. For example, the "Hello, world!" program given above would be rendered as below in Eiffel documentation:

classHELLO_WORLDcreatemakefeaturemakedoprint("Hello, world!")endend

Interfaces to other tools and languages

Eiffel is a purely object-oriented language but provides an open architecture for interfacing with "external" software in any other programming language.

It is possible for example to program machine- and operating-system level operations in C. Eiffel provides a straightforward interface to C routines, including support for "inline C" (writing the body of an Eiffel routine in C, typically for short machine-level operations).

Although there is no direct connection between Eiffel and C, many Eiffel compilers (Visual Eiffel is one exception) output C source code as an intermediate language, to submit to a C compiler, for optimizing and portability. As such, they are examples of transcompilers. The Eiffel Compiler tecomp can execute Eiffel code directly (like an interpreter) without going via an intermediate C code or emit C code which will be passed to a C compiler in order to obtain optimized native code. On .NET, the EiffelStudio compiler directly generates CIL (Common Intermediate Language) code. The SmartEiffel compiler can also output Java bytecode.

Related Research Articles

Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit features from more than one parent object or parent class. It is distinct from single inheritance, where an object or class may only inherit from one particular object or class.

In computer programming, a precondition is a condition or predicate that must always be true just prior to the execution of some section of code or before an operation in a formal specification.

In computer programming, a postcondition is a condition or predicate that must always be true just after the execution of some section of code or after an operation in a formal specification. Postconditions are sometimes tested using assertions within the code itself. Often, postconditions are simply included in the documentation of the affected section of code.

Generic programming is a style of computer programming in which algorithms are written in terms of data types to-be-specified-later that are then instantiated when needed for specific types provided as parameters. This approach, pioneered by the ML programming language in 1973, permits writing common functions or types that differ only in the set of types on which they operate when used, thus reducing duplicate code.

<span class="mw-page-title-main">F Sharp (programming language)</span> Microsoft programming language

F# is a general-purpose, strongly typed, multi-paradigm programming language that encompasses functional, imperative, and object-oriented programming methods. It is most often used as a cross-platform Common Language Infrastructure (CLI) language on .NET, but can also generate JavaScript and graphics processing unit (GPU) code.

In computer programming, a parameter or a formal argument is a special kind of variable used in a subroutine to refer to one of the pieces of data provided as input to the subroutine. These pieces of data are the values of the arguments with which the subroutine is going to be called/invoked. An ordered list of parameters is usually included in the definition of a subroutine, so that, each time the subroutine is called, its arguments for that call are evaluated, and the resulting values can be assigned to the corresponding parameters.

In computer programming, a function object is a construct allowing an object to be invoked or called as if it were an ordinary function, usually with the same syntax. In some languages, particularly C++, function objects are often called functors.

In computer science, type conversion, type casting, type coercion, and type juggling are different ways of changing an expression from one data type to another. An example would be the conversion of an integer value into a floating point value or its textual representation as a string, and vice versa. Type conversions can take advantage of certain features of type hierarchies or data representations. Two important aspects of a type conversion are whether it happens implicitly (automatically) or explicitly, and whether the underlying data representation is converted from one representation into another, or a given representation is merely reinterpreted as the representation of another data type. In general, both primitive and compound data types can be converted.

In computer programming, specifically object-oriented programming, a class invariant is an invariant used for constraining objects of a class. Methods of the class should preserve the invariant. The class invariant constrains the state stored in the object.

This article compares two programming languages: C# with Java. While the focus of this article is mainly the languages and their features, such a comparison will necessarily also consider some features of platforms and libraries. For a more detailed comparison of the platforms, see Comparison of the Java and .NET platforms.

In class-based, object-oriented programming, a constructor is a special type of function called to create an object. It prepares the new object for use, often accepting arguments that the constructor uses to set required member variables.

In software engineering, double dispatch is a special form of multiple dispatch, and a mechanism that dispatches a function call to different concrete functions depending on the runtime types of two objects involved in the call. In most object-oriented systems, the concrete function that is called from a function call in the code depends on the dynamic type of a single object and therefore they are known as single dispatch calls, or simply virtual function calls.

<span class="mw-page-title-main">C Sharp (programming language)</span> Programming language

C# is a general-purpose high-level programming language supporting multiple paradigms. C# encompasses static typing, strong typing, lexically scoped, imperative, declarative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines.

In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object or class, retaining similar implementation. Also defined as deriving new classes from existing ones such as super class or base class and then forming them into a hierarchy of classes. In most class-based object-oriented languages like C++, an object created through inheritance, a "child object", acquires all the properties and behaviors of the "parent object", with the exception of: constructors, destructors, overloaded operators and friend functions of the base class. Inheritance allows programmers to create classes that are built upon existing classes, to specify a new implementation while maintaining the same behaviors, to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed acyclic graph.

<span class="mw-page-title-main">Python syntax and semantics</span> Set of rules defining correctly structured programs

The syntax of the Python programming language is the set of rules that defines how a Python program will be written and interpreted. The Python language has many similarities to Perl, C, and Java. However, there are some definite differences between the languages. It supports multiple programming paradigms, including structured, object-oriented programming, and functional programming, and boasts a dynamic type system and automatic memory management.

C++11 is a version of the ISO/IEC 14882 standard for the C++ programming language. C++11 replaced the prior version of the C++ standard, called C++03, and was later replaced by C++14. The name follows the tradition of naming language versions by the publication year of the specification, though it was formerly named C++0x because it was expected to be published before 2010.

<span class="mw-page-title-main">EiffelStudio</span> Development environment

EiffelStudio is a development environment for the Eiffel programming language developed and distributed by Eiffel Software.

Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and code: data in the form of fields, and code in the form of procedures.

The following outline is provided as an overview of and topical guide to C++:

Objective-C is a high-level general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. Originally developed by Brad Cox and Tom Love in the early 1980s, it was selected by NeXT for its NeXTSTEP operating system. Due to Apple macOS’s direct lineage from NeXTSTEP, Objective-C was the standard programming language used, supported, and promoted by Apple for developing macOS and iOS applications until the introduction of the Swift programming language in 2014. Thereafter, its usage has been consistently declining among developers and it has often been described as a "dying" language.

References

  1. "Eiffel in a Nutshell". archive.eiffel.com. Retrieved 24 August 2017.
  2. "EiffelStudio 23.09 is available!". Eiffel.org. 25 October 2023.
  3. Cooper, Peter (2009). Beginning Ruby: From Novice to Professional. Beginning from Novice to Professional (2nd ed.). Berkeley: APress. p. 101. ISBN   978-1-4302-2363-4. To a lesser extent, Python, LISP, Eiffel, Ada, and C++ have also influenced Ruby.
  4. "Eiffel  the Language". berenddeboer.net. Retrieved 6 July 2016.
  5. Meyer, Bertrand (2009-08-28). Touch of Class: Learning to Program Well with Objects and Contracts. Springer Science & Business Media. ISBN   978-3-540-92144-8.
  6. "Programming Languages - Eiffel" (PDF). Department of Computer Science, Virginia Tech. Retrieved 25 March 2023.
  7. Carl Friess. "Eiffel Syntax Guide". Eiffel Syntax Guide. Retrieved 25 March 2023.
  8. Claus Brabrand. "The E I F F E L Programming Language" (PDF). IT University of Copenhagen. Retrieved 25 March 2023.
  9. Object-Oriented Software Construction, Second Edition, by Bertrand Meyer, Prentice Hall, 1997, ISBN   0-13-629155-4
  10. ECMA International: Standard ECMA-367  Eiffel: Analysis, Design and Programming Language 2nd edition (June 2006); available online at www.ecma-international.org/publications/standards/Ecma-367.htm
  11. International Organization for Standardization: Standard ISO/IEC DIS 25436, available online at
  12. Bertrand Meyer: Overloading vs Object Technology, in Journal of Object-Oriented Programming (JOOP), vol. 14, no. 4, October–November 2001, available online
  13. "9 INHERITANCE". Archive.eiffel.com. 1997-03-23. Retrieved 2013-07-08.
  14. "Multiple Inheritance and Interfaces". Artima.com. 2002-12-16. Retrieved 2013-07-08.
  15. "Multiple Inheritance Is Not Evil". C2.com. 2007-04-28. Retrieved 2013-07-08.
  16. Philippe Ribet, Cyril Adrian, Olivier Zendra, Dominique Colnet: Conformance of agents in the Eiffel language, in Journal of Object Technology , vol. 3, no. 4, April 2004, Special issue: TOOLS USA 2003, pp. 125-143. Available on line from the JOT article page
  17. Brooke, Phillip; Richard Paige (2008). "Cameo: An Alternative Model of Concurrency for Eiffel" (PDF). Formal Aspects of Computing. Springer. 21 (4): 363–391. doi:10.1007/s00165-008-0096-1. S2CID   18336088.
  18. Brooke, Phillip; Richard Paige (2007). "Exceptions in Concurrent Eiffel". Journal of Object Technology. 6 (10): 111–126. doi: 10.5381/jot.2007.6.10.a4 .