Re: Getter & Setter
- From: Jochen Theodorou <blackdrag@xxxxxxx>
- Date: Tue, 02 Dec 2008 00:21:46 +0100
Florian Weimer schrieb:
* Jochen Theodorou:
Florian Weimer schrieb:* Jochen Theodorou:Vorwärtsverbreitung von Typ-Informationen wäre doch schon mal ein
Es geht auch nicht direkt um Schwächen von Java in seinenMeinst Du echte Typinferenz oder bloße Vorwärtsverbreitung von
Konzepten. Aber die bisherige Weigerung zum Beispiel Typinferenz in
Java aufzunehmen in Kombination mit Generics halte ich für ein
brauchbares Beispiel.
Typ-Information? Echte Typinferenz ist ziemlich schwierig, braucht wohl
Row Types und ist u.U. nicht richtig verträglich mit der Einführung von
Closures.
Anfang. Das mit den Closures musst du mir aber mal kurz erklären, weil
ich zumBbeispiel auch nicht sicher bin was Row Types
Row Types sind so etwas wie ad-hoc-Interface-Typen, also "egal welche
Klasse, solange sie eine Methode foo(String) hat". Ich habe im
Hinterkopf, daß das herausbekommen von Varianz nicht ganz einfach ist,
und für die angepeilte knappe Closures-Syntax müßte man das wohl
machen.
Ich verstehe es nicht ganz fürchte ich. Meinst du sowas:
any x = foo.bar()
x.foo()
x.bar()
in der ersten Zeile setzt der Compiler für x eine Menge an möglichen Typen an. Zeile 2 kann erfolgreich compiliert werden, wenn die angesetzte Typmenge einen Typ mit der Methode foo() enthält. Entsprechendes gilt für Zeile 3. Sollte sich der Fall ergeben, dass entweder foo() oder bar() möglich ist, dann kann man nicht compilieren.
Allerdings reicht dafür die Vorwärtsverbreitung von Typinformation.... also meinst du das nicht. Hast du nicht mal einen Link der das ein wenig erklärt? Oder erklärst es selber ein wenig mehr?
Java ist mit dem Verzicht auf Typinferenz auch bei weitem nicht allein.Viele Sprachen machen das nicht, vorallem scheinen manche Leute zu
C++ und Ada machen das ebenfalls nicht (wobei Ada nur benannte Generics
hat und damit andere Probleme). Es gibt also in der Industrie eine lange
Tradition in diesem Bereich.
denken, dass das eine Domäne der funktionalen Sprachen sei und bleiben
müsse.
C++0X wird damit aufräumen, auto ist angenommen.
meinst du das gleiche auto wie hier? http://de.wikibooks.org/wiki/C%2B%2B-Programmierung:_Speicherverwaltung
[...]
Grundsätzlich halte ich Java gar nicht mal für *so* übel, was diesu meinst eine starke, statische Typisierung mit einigen
Balance zwichen Kosten und Nutzen durch Typisierung angeht.
Aufweichungen? Es gibt ja ganz verschiedene Typsysteme
Ja, mit Generics ist es doch gar nicht so schlimm. Jedenfalls kann man
die Sprache m.E. auch ohne IDE nutzen (auch wenn das vielleicht keine
mehrheitsfähige Meinung ist, weil JSR 269 schließlich sehr langsam
angenommen wird, wenn überhaupt).
JSR-000269 Pluggable Annotation Processing API
Was hat das mit Generics zu tun?
[...]
Allerdings muss man hier sehen, dass die "gute"
Performanz in Java hauptsächlich in den Methodenaufrufen zu finden
ist. Die sind wirklich schnell für eine objektorientierte Sprache.
Für eine objektorientierte Sprache, die eine offene Welt unterstützt
(also beliebigen Code zur Laufzeit nachladen kann), stimmt das. Mit
dem Aufwand, den man bis heute in die Referenzimplementierung gesteckt
hat und dem Wissen von heute hätte man wohl auch eine ähnlich
performante, weitaus dynamischere VM bauen können.
das ist schwer zu sagen. Parot zum Beispiel ist weit dynamischer als die JVM. Und deshlab hat diese VM andere Stärken und Schwächen. Ein Problem ist auch, dass in der Vergangenheit dynamische Sprachen oft Performancekillern gleichgesetzt wurden. Das brauchte einfach noch Zeit sich zu entwickeln
Von meiner Warte ist aber die Hauptkritik sowieso, daß Java vorrangig
eine Windows-Sprache ist, die nur halbherzig auf UNIX-ähnliche Systeme
(insbesondere solche mit lächerlich niedrigen Prozeßerzeugungskosten)
portiert wurde. 8-P
War danicht mal was mit Green-threads in der JVM, die jeden Thread in einem eigenem Thread laufen ließen? Aber wenn man vielen Leuten glauben darf, dann liegt die Zukunft eher in der Nutzung großer Mengen an Prozessoren und damit in der automatisierten Parallelisierung von Algorithmen.
Ich jedenfalls sehe die Optimierung eher in der Wahl von single
dispatch anstatt von multiple dispatch, als daran statische Typen zu
wählen.
Die Möglichkeit, sehr einfach Ganz- und Gleitkommazahlen in Registern
zu übergeben und nicht geboxte Felder zu implementieren, ist m.E.
nicht zu unterschätzen. Das sind jedenfalls Dinge, die die Sprache
deutlich komplizierter machen, aber auch effizienteren Code gestatten
(bzw. dessen Erzeugung erheblich vereinfachen).
IMHO wäre der Aufwand nicht notwendig gewesen. Ich bin davon überzeugt, dass man mit leichten Anpassungen jeden Primtivwert wie eine Instanz behandeln könnte. Das Problem liegt eher in der Beschreibung der Sprache selbst und so Sachen wie widenig und zum Beispiel 1.0f == 1.0d. Wären das Objekte, dann dürfte das ja niemals in Java true ergeben. Und dann ist man mit Auto-boxing doch irgendwie zum Teil diesen Pfad gegangen.. allerdings ohne die VM-Optimierung, die ich mir dafür gewünscht hätte.
Gruss theo
.
- References:
- Re: Getter & Setter
- From: Florian Weimer
- Re: Getter & Setter
- Prev by Date: Re: Properties Pattern Dialog in NetBeans
- Next by Date: Re: kartenkomponente für Dispo
- Previous by thread: Re: Getter & Setter
- Next by thread: Re: Modell fuer Eingabefelder
- Index(es):
Relevant Pages
|
