[Eiffel] Standard-Library?

10/10/2008 - 14:35 von Thomas Preymesser | Report spam
Hallo,

wo ist denn eigentlich festgelegt, wie Standard-Libraries für Eiffel
auszusehen haben? Gibt es da einen allgemeinen Standard?
Ich bin beispielsweise über folgendes Beispiel gestolpert. Ein
Projekt, das in einem Tutorial erklàrt wird, verwendet, wie
nachfolgend zu sehen, eine Methode ‘putreal’, welche zumindest bei
meinem Smart Eiffel? Compiler so überhaupt nicht vorhanden ist.
Verwenden die jetzt einfach nur eine Methode, die nur in einer anderen
Entwicklungsumgebung vorhanden ist? Ich meine, es sollte doch
eigentlich nicht sein, daß solche allgemeinen Klassen so
unterschiedlich aufgebaut sind.

****** Error: Current type is STD_INPUT_OUTPUT. There is no feature
putreal in class STD_INPUT_OUTPUT.
Line 41 column 7 in ACCOUNT (/home/tp/eiffel-test/bank/account.e) :
io.putreal (balance)
^

****** Fatal Error: Feature "putreal" not found.
Line 41 column 7 in ACCOUNT (/home/tp/eiffel-test/bank/account.e) :
io.putreal (balance)
^


Außerdem hatten sie ‘io.new_line’ verwendet, wàhrend mein Compiler
‘io.put_new_line’ verlangt.

Von den unterschiedlichen Namen abgesehen – warum heißt diese Methode
eigentlich ‘putreal’? Ich hàtte sie einfach nur ‘put’ genannt, weil
bei einer Real Zahl doch sowieso klar ist, daß ein Real Objekt
ausgegeben werden soll. Oder übersehe ich hier einen Aspekt, warum man
das so genannt hat?
 

Lesen sie die antworten

#1 Georg Bauhaus
10/10/2008 - 19:25 | Warnen spam
Thomas Preymesser schrieb:

Hallo,

wo ist denn eigentlich festgelegt, wie Standard-Libraries für Eiffel
auszusehen haben? Gibt es da einen allgemeinen Standard?
Ich bin beispielsweise über folgendes Beispiel gestolpert. Ein
Projekt, das in einem Tutorial erklàrt wird, verwendet, wie
nachfolgend zu sehen, eine Methode ‘putreal’, welche zumindest bei
meinem Smart Eiffel? Compiler so überhaupt nicht vorhanden ist.



SmartEiffel ist (a) nicht Standard (ISO) Eiffel und das team
(b) gelassen und stolz auf diese Abweichung, weil wie (c)
ein etwas ursprünglicheres Eiffel (ETL2(3)) weiter zu
entwickeln angeben. Die agents sind derzeit auch etwas anders
aufgebaut, je nach dem ob man ISE Eiffel (auch als GPL)
oder SmartEiffel verwendet. Ist vielleicht ein Ausfluss
der Anschauungen: akademische Compilerbau-Freiheit (SmartEiffel)
versus ECMA-getriebene Standardisierung (ISE, ETHZ).

Die klassischen Kernel (ELKS) -Klassen sollten allerdings
mindestens in jeder Umgebung verfügbar und weitestgehend
kompatibel sein. Die Basisklassen werde derzeit scheinbar
überarbeitet, das ein oder andere ist im Umbau, wohl insofern
die Basistypen (Zahlen, z.B.) nicht so recht in das EIAO-Modell
passen wollen (ref/expanded/32 bzw 64 bit usw.).

I/O wird beim Sprachentwurf doch fast immer vernachlàssigt,
da sollte es nicht wundern, wenn auch in Eiffel das übliche
I/O-Chaos regiert :-) :-)

Zwar macht das LORIA-team fast alles selbst, und macht auch
zwingende stilistischer Vorgaben. Man ist
nicht so interessiert, wenn die in deren Folge die
Gobo-Klassenbibliothek -- von vielen für unentbehrlich
gehalten -- nicht mehr übersetzt werden kann (großenteils
wegen führender Unterstriche in einigen Klassennamen).
Aber dafür fließt einiger Enthusiasmus in die eigenen
Varianten einer Auswahl vergleichbarer Klassen. Mit
je eigenen Routinen-Namen.

SmartEiffel ist zur Zeit auch nicht besonders thread-sicher.
Neue Versionsn kommen auch gern mit den Optimierern des
GCC C-compilers in Konflikt. Aber daran wird gearbeitet.

Ähnliche fragen