Diskussion:Eiffel (Programmiersprache)

aus Wikipedia, der freien Enzyklopädie

Ein falscher Fehler, Herr Tesuji. Mit Reverenz ist wirklich Reverenz gemeint (im Sinne von Ehrerbietung, Verbeugung, vor den Ingenieurtechnischen Leistungen nämlich). Referenz mein allgemein laut Duden Beziehung, Empfehlung, das macht hier keinen Sinn. Und die Bedeutung, die dieser Begriff bzgl Computersprachen (etwa Verweis) hat, sollte auch nicht verwendet werden, da zu speziell.

In der Tat, ich habe wohl unbewusst an letztere Bedeutung gedacht und entschuldige mich für diese voreilige Korrektur. Tesuji 13:05, 4. Jun 2003 (CEST)

Diese Änderung ist gerade nochmal vorgekommen und wurde von mir revertiert --Karljunk 22:10, 1. Apr 2005 (CEST)

Warum nicht einfach "Hommage" oder sowas? Oder eben "Verbeugung", "Verneigung"? Ich wollte grad ebenfalls das "v" zum "f" machen ;) denke mal daß das Wort kaum einer kennt - bzw. 'ne Alternative wäre es noch, aus dem Wort einen Link auf einen Artikel "Reverenz" zu machen ;) dann wüßte man immerhin, daß dieses Wort existiert.

Inhaltsverzeichnis 1 Überladen von Operatoren 2 Der ECMA Eiffel Standard 3 wird GEC den Status von SmartEiffel einnehmen? 4 EiffelStudio unter GPL

[Bearbeiten] Überladen von Operatoren

Das stand offenbar von Anfang an im Artikel. Gibt es aber in Eiffel nicht, und zwar mit Absicht. Jedes Feature hat eine Signatur, und die bleibt bei der Vererbung erhalten. Höchstens können die Typen durch Unterklassen-Typen der originalen Typen ersetzt werden, die aber konform zu den Oberklassen sein müssen. --Karljunk 04:53, 19. Mär 2005

Ich zitiere mal aus einer Publikation von Interactive Software Engineering Inc. von 1987:

operator overloading
The term "operator overloading" is not entirely adequate since the issue is whether functions may be assigned names that will be used in prefix or infix form in calling expressions. This is a syntactic, not a semantic issue; the more impotant form of overloading, the semantic one, is provided in the object-oriented context by redefinition and dynamic binding.
C++ offers the possibility of using an operator (from a set of predefined ones) as function name. Eiffel offers "prefix" and "infix" operators, which achieve the same purpose. So there is no significant difference between the two languages here.

dibe 00:16, 23. Mär 2005 (CET)

Ich zitiere mal aus Eiffel, the Language (1992), Seite 17, nach dem die Vorteile von "dynamic Binding" erklärt wurden: "This technique is particularly attractive when compared to its closest equivalent in traditional approaches. In Pascal or Ada, you would need records with variant components, ... The Ada facilities for overloading and genericity do not bring any improvement to this respect ...". Ich wüsste nicht, wo sonst in diesem Buch noch von "overloading" die Rede ist. Tatsächlich ist wohl das Überladen von Funktionen und Operatoren durch Ada populär geworden. Dort kann man schon seit jeher - lange bevor die objektorientierte Programmierung populär wurde, Funktionen und Operatoren mehrfach definieren mit jeweils verschiedenen Parameterlisten. Dies ist sicherlich von Übel, denn wie leicht kann man einen aktuellen Parameter mit einem ungewollten Typ erwischen, und der Compiler akzeptiert es, führt aber dann eine ganz andere Routine aus als gedacht. Solche Fehler sind sicher schwierig zu finden. Das C++ Beispiel, dass sich unter [Überladen] findet, geht in Eiffel genausowenig, da es der gleiche Scheiß wie in Ada ist. Wenn man sowas objektorientiert machen will, dann muss man ganz anders vorgehen, nämlich wie z. B. bei der Funktion abs in NUMERIC, die durch dynamisches binden auch auch auf sowohl INTEGER als auch DOUBLE targets angewandt werden kann. Dann heist es aber nicht abs(n), sondern n.abs. Das ist etwas so fundamental anderes, dass ich denke, der Begriff Überladen sollte nur für den objektorientierten Ansatz nicht verwendet werden sollte. In C++ geht natürlich beides, aber nur eines sollte Überladen heißen. Und das ist der "traditional approach".

--Karljunk 18:20, 23. Mär 2005 (CET)

Ich kenn mich mit Ada nicht so aus, komme eher von C++, wo "operator overloading" eigentlich nicht viel mehr meint als Operatoren für Klassen zu definieren; aber da das auch im vom mir zitierten Text gesagt wird, "operator overloading" sei nicht eine entirely adequate bezeichnung, sollte man vielleicht nur schreiben: Definition von Prä- und Infix-Operatoren möglich.

dibe (z.Z. ausgeloggt)

Habe ich eben so ähnlich eingefügt. Mir schien es sinnvoll, die Wesensgleichheit von Operator auf Funktion in Eiffel hervorzuheben. --Karljunk 18:05, 30. Mär 2005 (CEST)

[Bearbeiten] Der ECMA Eiffel Standard

Ich habe die Seite mal überarbeitet, um die Änderungen durch den ECMA-Eiffelstandard und diesen selbst einzupflegen.

Außerdem ist SmartEiffel (leider) kein "richtiger" Eiffel-Compiler mehr. 1. weicht es schon jetzt von bisherigen Eiffel-Gepflogenheiten weit ab (z.B. Unterscheidung von Groß/Kleinschreibung inzwischen verpflichtend; auch bestimmte Benennungen (Klassen immer GROSS, formale generische Parameter müssen Postfix _ besitzen, Features klein), die vorher nur Stilfragen waren). 2. haben die Entwickler mehrfach auf ihren Mailinglisten angekündigt, den ECMA-Standard nicht umzusetzen und in ihre eigene Richtung weiterzuentwickeln.

Eine interessante Neuentwicklung ist GEC, der Eiffel-Compiler der Gobo-Bibliothek. Dieser wird wohl über kurz oder lang den Platz von SmartEiffel einnehmen (Mutmaßung und daher nicht im Artikel eingefügt).

[Bearbeiten] wird GEC den Status von SmartEiffel einnehmen?

Das wage ich zu bezweifeln, weil gec versucht ja sofern ich recht informiert bin ECMA-Eiffel zu implementieren, was sehr umstritten ist. Es gibt einige Meinungen, dass der Dialekt von SmartEiffel besser den Ideen von Eiffel (im ursprünglichen Sinn) entspricht, als der "Standard". Meine Prognose ist, dass SmartEiffel eine Sprache wird die sich verbessert, und es erleichtert sichere Software zu entwickeln. Der ECMA-Standard - von dem man munkelt, er könne überhaupt nicht auf sinnvolle Art und Weise implementiert werden führt viele von den Dingen ein, die Sprachen wie C++ so hässlich machen. (z. B. wird meiner Meinung nach viel zu viel implizit gemacht: automatic boxing, convertion features, ... was zu immer undurchsichtigerem Code führt). Die Ausführungs-Performance von SmartEiffel gegenüber ISE Eiffel ist ja unumstritten und kann wohl auch mit dem ECMA-Standard nie erreicht werden. Natürlich ist bei SmartEiffel einiges schief gelaufen und es werden immer wieder Änderungen in der Sprache eingeführt, die die Rückwärtskompatibilität einschränken, aber das ist etwas das ich Fortschritt nennt - auch wenn es auch in meinen Augen nicht immer gerechtfertigt war.

[Bearbeiten] EiffelStudio unter GPL

"mit SmartEiffel (ehemals SmallEiffel, siehe Abschnitt Weblinks) und dem sich aktuell in Entwicklung befindlichen GEC (aus der Gobo Klassenbibliothek, siehe Abschnitt Weblinks) mindestens zwei Open-Source-Compiler." wiederspricht "Anfang April 2006 wurde der Quelltext von EiffelStudio, eine plattformübergreifende integrierte Entwicklungsumgebung von Eiffel Software, als Freie Software veröffentlicht." - es gibt also 3 Open-Source-Compiler, wobei einer aus der akademischen Welt, einer in Privatleistung und einer durch Firmenentwicklung entstanden ist. Der letzte Paragraph sollte in den ersten integriert werden. Ausserdem könnte man nennen, dass EiffelStudio unter der GPL publiziert wurde. --Schoelle 16:51, 1. Feb. 2007 (CET)