Discussion:
[RFE] Field, Method und Constructor Objekte ohne Strings zu verwenden
(zu alt für eine Antwort)
Carl Rosenberger
2004-05-10 22:16:33 UTC
Permalink
Hallo,

um folgenden RFE eingetragen zu bekommen, habe ich 2 Jahre
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Ich würde mich sehr über rege Unterstützung durch Eure Stimmen
freuen. Ich würde dieses Feature lieben.

Vielen Dank!

Viele Grüße,
Carl
Jochen Theodorou
2004-05-11 01:20:53 UTC
Permalink
Post by Carl Rosenberger
Hallo,
um folgenden RFE eingetragen zu bekommen, habe ich 2 Jahre
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Ich würde mich sehr über rege Unterstützung durch Eure Stimmen
freuen. Ich würde dieses Feature lieben.
gerne, aber da ist nichts grundsätzlich neues zu 4810162, oder?

Problem ist auch dass die Syntax nicht ganz passt. Warum nicht sowas wie

Field fooBarField = Foo#bar;
Method fooFlyMethod = Foo#fly(new Object[]{String.class});
Constructor fooConstructor = Foo#(new Object[]{String.class});

wobei es komisch wäre hier plötzlich Foo für die Klasse schreiben zu
können also entweder

Field fooBarField = Foo#bar;
Method fooFlyMethod = Foo#fly(new Object[]{String});
Constructor fooConstructor = Foo#(new Object[]{String});

oder

Field fooBarField = Foo.class#bar;
Method fooFlyMethod = Foo.class#fly(new Object[]{String.class});
Constructor fooConstructor = Foo.class#(new Object[]{String.class});

Von mir aus auch mit ::, wobei man # von Javadoc her gewohnt.
Ich meine der Compiler muss so oder so geändert werden. Warum dann nicht
eine etwas kürzere Schreibweise nutzen.

Gruss theo
Carl Rosenberger
2004-05-11 09:42:07 UTC
Permalink
Post by Jochen Theodorou
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Ich würde mich sehr über rege Unterstützung durch Eure Stimmen
freuen. Ich würde dieses Feature lieben.
gerne, aber da ist nichts grundsätzlich neues zu 4810162, oder?
Stimmt, das sieht sehr ähnlich aus.

Irgendwie scheine ich diesen RFE auch schon zu kennen,
denn da steht ein Kommentar von mir.

Ich meine mich aber erinnern zu können, daß dieser RFE
schon als abgelehnt markiert war. Jetzt ist er wieder
offen. Der Kommentar des "Evaluators" ist aber nicht
sehr vielversprechend.
Post by Jochen Theodorou
Problem ist auch dass die Syntax nicht ganz passt.
Ich finde sie auch nicht toll.
Deine Schreibweisen gefallen mir ganz entschieden besser.

Magst Du sie als Kommentar zum RFE auf der Website vorschlagen?

Wenn Du das nicht tust, mache ich das gerne.
Post by Jochen Theodorou
Warum nicht sowas wie
Field fooBarField = Foo#bar;
Method fooFlyMethod = Foo#fly(new Object[]{String.class});
Constructor fooConstructor = Foo#(new Object[]{String.class});
Absolut perfekt!
Danke!


Viele Grüße,
Carl
Jochen Theodorou
2004-05-11 14:10:16 UTC
Permalink
Post by Carl Rosenberger
Post by Jochen Theodorou
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Ich würde mich sehr über rege Unterstützung durch Eure Stimmen
freuen. Ich würde dieses Feature lieben.
gerne, aber da ist nichts grundsätzlich neues zu 4810162, oder?
Stimmt, das sieht sehr ähnlich aus.
Irgendwie scheine ich diesen RFE auch schon zu kennen,
denn da steht ein Kommentar von mir.
Ich dachte der wäre von dir;)
Post by Carl Rosenberger
Ich meine mich aber erinnern zu können, daß dieser RFE
schon als abgelehnt markiert war. Jetzt ist er wieder
offen. Der Kommentar des "Evaluators" ist aber nicht
sehr vielversprechend.
Stimmt.
Post by Carl Rosenberger
Post by Jochen Theodorou
Problem ist auch dass die Syntax nicht ganz passt.
Ich finde sie auch nicht toll.
Deine Schreibweisen gefallen mir ganz entschieden besser.
Magst Du sie als Kommentar zum RFE auf der Website vorschlagen?
Hab ich gerade gemacht, vielleicht hilft es ja, dass da nicht wieder
irgendwelche Missverständnisse auftauchen.
Post by Carl Rosenberger
Wenn Du das nicht tust, mache ich das gerne.
Ich habe mich recht knapp ausgedrückt, wenn etwas wichtiges fehlt
ergänze es bitte.

Bin ja mal auf die ersten Kommentare von anderen gespannt;)

Gruss theo
Carl Rosenberger
2004-05-11 15:30:49 UTC
Permalink
Post by Jochen Theodorou
Post by Carl Rosenberger
Irgendwie scheine ich diesen RFE auch schon zu kennen,
denn da steht ein Kommentar von mir.
Ich dachte der wäre von dir;)
...bevor ich Alzheimer hatte.

Wer ist eigentlich der hübsche junge Mann im Spiegel?
Post by Jochen Theodorou
Post by Carl Rosenberger
Deine Schreibweisen gefallen mir ganz entschieden besser.
Magst Du sie als Kommentar zum RFE auf der Website vorschlagen?
Hab ich gerade gemacht, vielleicht hilft es ja, dass da nicht wieder
irgendwelche Missverständnisse auftauchen.
Perfekt, vielen Dank, ich habe noch meinen Senf dazu gegeben.

Ein paar weitere "Vote"s wären fein, wenn jemand noch ein Stimmchen
übrig hat:
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html

Wer votet eigentlich aus dclj überhaupt bei RFEs mit?
Stimmungen, Meinungen, Kommentare, Erlebnisberichte, Poesiealben? °


Carl
Alexander Reifinger
2004-05-11 15:26:12 UTC
Permalink
Post by Carl Rosenberger
Ein paar weitere "Vote"s wären fein, wenn jemand noch ein Stimmchen
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Wer votet eigentlich aus dclj überhaupt bei RFEs mit?
Stimmungen, Meinungen, Kommentare, Erlebnisberichte, Poesiealben? °
Also mir gefällt Jochens Vorschlag und ich habe meinen Send^H^H^H^HVote
dazugegeben...

Jeder Fehler mehr der vom Compiler abgefangen werden kann ist ein (fast)
gelöster Fehler.
--
Servus,
Alexander Reifinger
Stefan Matthias Aust
2004-05-11 07:34:45 UTC
Permalink
Post by Carl Rosenberger
um folgenden RFE eingetragen zu bekommen, habe ich 2 Jahre
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Nach wie vor gefällt mir die Syntax nicht und IMHO forderst du nur eins:

Keine checked Exceptions bei Reflections.

Ob du nun

Field f = Foo.class.toString.method()

oder

Field f = Foo.class.getMethod("toString"); // ab 1.5

schreibst - ich erkenne keinen wirklichen Unterschied. Du könntest
sagen, dass der Compiler im ersten Fall zur Übersetzungszeit prüfen
kann, ob "Foo" wirklich eine "toString"-Methode hat, aber zum Zeitpunkt
des Ausführens des Codes muss das nicht mehr zutreffen und du kannst
nicht garantieren, dass keine Exceptions auftreten. Der zusätzliche
Compilertest rechtfertigt IMHO nicht den Extraaufwand (gleiches empfinde
ich auch bei generics a la Java). Meine Variante zur Übersetzungszeit
prüfen könnte auch jede bessere IDE.

Wenn du Java weiterentwickeln willst, dann mache lieber Klassen und
Methoden zu 1st class Objekten, d.h.

Foo

steht für das Klassenobjekt und

Foo.toString

steht für das Methodenobjekt. Dann würde z.B.

Class[Foo] c = Foo;
String method() m = c.toString;
m();

funktionieren. Allerdings auch eine dumme C-ähnliche Syntax, die das
Schlüsselwort "method" mitten in die Typdefinition reinschreibt.
Vielleicht besser

String() m = Foo.toString

Ach was, auch häßlich. Versteht wahrscheinlich auch der gemeine
Java-Entwickler nicht. Dann lieber C# 2.0 mit delegates und echten
closures... Klassenobjekte haben die allerdings auch nicht und der
dynamische Umgang mit Klassen wie bei Java ist auch nur mit großen
Schmerzen möglich.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Carl Rosenberger
2004-05-11 10:03:49 UTC
Permalink
Post by Stefan Matthias Aust
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Nach wie vor gefällt mir die Syntax nicht
Mir auch nicht.

Theo's Vorschlag finde ich super, wie gesagt.
Post by Stefan Matthias Aust
Keine checked Exceptions bei Reflections.
Ob du nun
Field f = Foo.class.toString.method()
oder
Field f = Foo.class.getMethod("toString"); // ab 1.5
schreibst - ich erkenne keinen wirklichen Unterschied.
Ich sehe schon Unterschiede:

- Man würde auf jeden Fall einen Compile-Time Check in den
Compiler einbauen.

- Bestehende IDEs würden faktisch gezwungen, ihre Refactorings
an das neue Feature anzupassen.
Post by Stefan Matthias Aust
Du könntest
sagen, dass der Compiler im ersten Fall zur Übersetzungszeit prüfen
kann, ob "Foo" wirklich eine "toString"-Methode hat, aber zum Zeitpunkt
des Ausführens des Codes muss das nicht mehr zutreffen und du kannst
nicht garantieren, dass keine Exceptions auftreten.
Es kann immer ein byte aus dem ByteCode wegbrechen, ein Komet
einschlagen oder das Zeitkontinuum stehen bleiben.

Die Wahrscheinlichkeit, daß das zur Kompilier-Zeit gefundene Attribut
zur Lauf-Zeit noch da ist, ist mit meinem Vorschlag aber ganz deutlich
höher.

Tipfehler werden völlig ausgeschlossen.

Die "Verlinkung" ist vergeleichbar direkt wie ein Methodenaufruf in eine
andere Jar.
Post by Stefan Matthias Aust
Der zusätzliche
Compilertest rechtfertigt IMHO nicht den Extraaufwand (gleiches empfinde
ich auch bei generics a la Java).
Welcher Extraaufwand für wen?
Ich möchte wetten, daß der weltweite jährliche Aufwand, Strings in
Reflection zu refakturieren und zu fixen, den weltweiten Aufwand
zum Einbau des Features in alle Compiler und IDEs um das Hunderfache
übertrifft.
Post by Stefan Matthias Aust
Meine Variante zur Übersetzungszeit prüfen könnte auch jede
bessere IDE.
Sie können es aber noch nicht und sie refakturieren es auch nicht.
Es ist in vielen Fällen auch hässlich einzubauen. Was sollte die
IDE in folgendem Fall machen:

class Foo {

static final String UNIVERSAL_FIELD_PREFIX = "f_";
static final String FIELD_BAR = UNIVERSAL_FIELD_PREFIX + "bar";

String f_bar;

static Field getTheImportantField(){
return Foo.class.getField(FIELD_BAR);
}
}

Ein Check ist gerade noch möglich aber ich kann das Beispiel
gerne noch komplexer oder nicht-statisch machen, dann geht
auch kein Check mehr.

Eine automatische Refakturierung kannst Du schon bei diesem
simplen Beispiel vergessen.
Post by Stefan Matthias Aust
Wenn du Java weiterentwickeln willst, dann mache lieber Klassen und
Methoden zu 1st class Objekten, d.h.
Der Zug ist abgefahren, fürchte ich.

Da würde zu viel Code kaputt gehen.
Post by Stefan Matthias Aust
Foo
steht für das Klassenobjekt und
Foo.toString
steht für das Methodenobjekt.
Das würde mir sehr gut gefallen aber das wäre ein zu drastischer
Eingriff.

Theo's Vorschlag könnte gerade mal so eben noch durch kommen.
...schon allein weil er genau der Schreibweise entspricht, die
man sich beim Dokumentieren ohnehin angewöhnt hat.


Viele Grüße,
Carl
Stefan Matthias Aust
2004-05-12 08:29:05 UTC
Permalink
Post by Carl Rosenberger
Theo's Vorschlag finde ich super, wie gesagt.
Die Syntax ist in der Tat besser...
Post by Carl Rosenberger
- Man würde auf jeden Fall einen Compile-Time Check in den
Compiler einbauen.
Halte ich nicht für wichtig. Ich habe inzwischen mehrere Anwendungen
zum Spass von 1.4 in 1.5 generics umgeschrieben und bis lang noch nicht
einmal von den zusätzlichen Checks provitieren können... daraus folgere
ich, dass ich auch bei zur Überstezungszeit geprüften Methodennamen
keinen wesentlich Vorteil ziehen kann.
Post by Carl Rosenberger
- Bestehende IDEs würden faktisch gezwungen, ihre Refactorings
an das neue Feature anzupassen.
Das halte ich eher für einen Nachteil. Man sieht ja bei 1.5, welchen
Aufwand das bedeutet. Jeder muss seinen Compiler anpassen. Ich denke,
die neue Sytanx wird auch dazu führen, dass 1.5 nur sehr zögerlich
eingeführt werden wird.
Post by Carl Rosenberger
Die Wahrscheinlichkeit, daß das zur Kompilier-Zeit gefundene Attribut
zur Lauf-Zeit noch da ist, ist mit meinem Vorschlag aber ganz deutlich
höher.
Nein, die Wahrscheinlichkeit ist konstant (AFAIK, Mathematiker an die
Front). Es geht hier nicht Kometeneinschläge sondern um beim nachladen
von Klassen, verteilten Anwendungen u.ä. konkret vorkommenden Konflikten
zwischen class files.
Post by Carl Rosenberger
Tipfehler werden völlig ausgeschlossen.
Nein. Wenn du zwei Methoden al und a1 hast, kann der Compiler bei a1
immer noch nicht entscheiden, ob die nicht al gemeint hast.
Post by Carl Rosenberger
Post by Stefan Matthias Aust
Der zusätzliche
Compilertest rechtfertigt IMHO nicht den Extraaufwand (gleiches empfinde
ich auch bei generics a la Java).
Welcher Extraaufwand für wen?
Bei generics der Extra-Lernaufwand. Der Extra-Lehraufwand und die
extra-Zeit, die man jetzt braucht, weil man nicht versteht, warum es
"so" und nicht "so" funktioniert.
Post by Carl Rosenberger
Ich möchte wetten, daß der weltweite jährliche Aufwand, Strings in
Reflection zu refakturieren und zu fixen, den weltweiten Aufwand
zum Einbau des Features in alle Compiler und IDEs um das Hunderfache
übertrifft.
Diese Wette würdest du gewinnen, aber Compilerbauer und Anwender wetten
glaube ich nicht miteinander... will sagen: Niemand vergleicht diese
Punkte. Ansonsten würde man nicht weltweit mit Sprachen wie Cobol, C,
Java arbeiten, sondern mit "typsicheren" Sprachen wie Eiffel, Beta (die
haben doch diesen Anspruch, oder?), Haskell, usw.
Post by Carl Rosenberger
Sie können es aber noch nicht und sie refakturieren es auch nicht.
Es ist in vielen Fällen auch hässlich einzubauen. Was sollte die
class Foo {
static final String UNIVERSAL_FIELD_PREFIX = "f_";
static final String FIELD_BAR = UNIVERSAL_FIELD_PREFIX + "bar";
String f_bar;
static Field getTheImportantField(){
return Foo.class.getField(FIELD_BAR);
}
}
Da hat sie keine Chance. Aber diesen Fall kannst du auch nicht mit
deinem Ansatz abdecken. Also ist das kein fairer Vergleich. Du willst
ja gerade literale hinschreiben. Und diese kann ich eben auch als
String finden. Eclipse kann ja auch Methoden und Klassenliterale in
Javadoc-Kommentaren mit refaktorieren. Wo ist also das Problem?
Post by Carl Rosenberger
Post by Stefan Matthias Aust
Wenn du Java weiterentwickeln willst, dann mache lieber Klassen und
Methoden zu 1st class Objekten, d.h.
Der Zug ist abgefahren, fürchte ich.
Mein Tipp wäre momentan, dass Java 1.5 die letzte Änderung der
Sprachsyntax bringt. Vielleicht wird es in zwei Jahren noch ein Java
1.6 geben, aber das wird wieder nur Bibliotheken hinzufügen und Wünsche
erfüllen, die sich aus bestehenden Projekten ergeben.

Als Sprache für Neuentwicklungen wird dann wahrscheinlich etwas anderes
benutzt... ich glaube nicht, dass Java dann noch eine plattform für
spannende neue Konzepte bietet.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Carl Rosenberger
2004-05-12 11:33:31 UTC
Permalink
Post by Stefan Matthias Aust
Post by Carl Rosenberger
- Man würde auf jeden Fall einen Compile-Time Check in den
Compiler einbauen.
Halte ich nicht für wichtig. Ich habe inzwischen mehrere Anwendungen
zum Spass von 1.4 in 1.5 generics umgeschrieben und bis lang noch nicht
einmal von den zusätzlichen Checks provitieren können... daraus folgere
ich, dass ich auch bei zur Überstezungszeit geprüften Methodennamen
keinen wesentlich Vorteil ziehen kann.
Du weist aber schon, wofür ich mir das Feature wünsche?
Ich will Datenbankabfragen auf Felder einschränken.
Da kommen ganz regelmässig von Kunden die Kommentare:
(1) Wie kann ich das refakturieren?
(2) Das ist aber nicht Compile-Time-gecheckt. Geht das irgendwie?
(3) Ich will die interne Implementation der Klasse nicht in meiner
Abfrage drin haben.

Für den dritten Punkt will ich Abfragen mittelfristig auch über
Methoden einschränken können (auch ohne Strings) und auch die
Ergebnisse von Methoden in Indizes vorhalten.

<Exkurs>
Zugegen, wenn man das Ergebnis einer Methode indiziert, kann man die
Implementation der Methode nicht mehr ändern, ohne den Index neu
aufbauen zu müssen. Dann ist der Vorteil der Kapselung sehr viel
geringer und man kann eigentlich gleich ein Feld verwenden.

Ich verwende in internen Implementationen, die ich komplett alleine
schreibe immer weniger gekapselten Zugriff und baue ihn erst dann
ein, wenn ich ihn brauche.
</Exkurs>

Zu Generics:
Ich habe noch nicht damit gearbeitet aber ich denke auch, daß ich sie
nicht brauche. In der Regel weiß ich, was ich in Collections aufhebe
und so langsam ist man an das Casten schon gewöhnt und man kann sich
sogar mit Eclipse QuickFix das manuelle Tippen der Casts sparen.
Post by Stefan Matthias Aust
Nein, die Wahrscheinlichkeit ist konstant (AFAIK, Mathematiker an die
Front). Es geht hier nicht Kometeneinschläge sondern um beim nachladen
von Klassen, verteilten Anwendungen u.ä. konkret vorkommenden Konflikten
zwischen class files.
Dann muß ich mich wohl exakter ausdrücken.

Gegeben sei:

class Foo{
int barbarzargarnarharhar;
}

Als alternative Schreibweisen stehen zur Debatte:

(1) Field f = Foo#barbarzargarnarharhar;

(2) Field f = Foo.class.getField("barbarzargarnarharhar");


Für Version 2 muß man den String komplett von Hand schreiben.

Bei Version 1 kann einem die IDE mit AutoKomplettierung helfen.


Ich behaupte:

Wenn man hunderttausend mal Version 1 mit Autokomplettierung
schreibt, macht man dabei keinen einzigen Fehler.

Für Version 2 braucht man bei der Eingabe deutlich länger und
man müßte eine Maschine sein, wenn man sich nie vertippt.
Aus dem Handgelenk kann ich das nicht beweisen aber Du kannst
es ja mal ausprobieren.

Die Wahrscheinlichkeit, bei hunderttausend manuellen Eingaben
einen Fehler zu machen ist also bei Version 2 ganz entschieden
höher als bei Version 1.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Tipfehler werden völlig ausgeschlossen.
Nein. Wenn du zwei Methoden al und a1 hast, kann der Compiler bei a1
immer noch nicht entscheiden, ob die nicht al gemeint hast.
KorinthenK..
SCNR

Zugegebermassen hast Du Recht, aber mit Deiner Argumentation negierst
Du den Vorteil von Compile-Time-Checks völlig.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Welcher Extraaufwand für wen?
Bei generics der Extra-Lernaufwand. Der Extra-Lehraufwand und die
extra-Zeit, die man jetzt braucht, weil man nicht versteht, warum es
"so" und nicht "so" funktioniert.
Das ist natürlich ein Argument.

Haben wir nicht vor drei Jahren ausgemacht, daß wir uns in
"fünf Jahren" etwas eigenes ausdenken? Ich fürchte, bei mir
wird es eher noch 10 Jahre dauern.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
class Foo {
static final String UNIVERSAL_FIELD_PREFIX = "f_";
static final String FIELD_BAR = UNIVERSAL_FIELD_PREFIX + "bar";
String f_bar;
static Field getTheImportantField(){
return Foo.class.getField(FIELD_BAR);
}
}
Aber diesen Fall kannst du auch nicht mit
deinem Ansatz abdecken. Also ist das kein fairer Vergleich. Du willst
ja gerade literale hinschreiben.
O.K. einverstanden, das ist auch ein Argument.
Das Problem bei meinem Anwendungsfall für Literale:
Es würde der IDE recht schwer fallen, aus dem Kontext der Methode auf die
Klasse schliessen zu können, die gemeint ist. Man kann das sicher in
Eclipse einbauen, aber es ist nicht trivial.

Ich muß auch gestehen, mir ist sehr viel lieber, wenn das Eclipse-Team
das macht, als wenn ich aus meinem Umfeld sehen muß, wie das erledigt
wird.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Post by Stefan Matthias Aust
Wenn du Java weiterentwickeln willst, dann mache lieber Klassen und
Methoden zu 1st class Objekten, d.h.
Der Zug ist abgefahren, fürchte ich.
Mein Tipp wäre momentan, dass Java 1.5 die letzte Änderung der
Sprachsyntax bringt. Vielleicht wird es in zwei Jahren noch ein Java
1.6 geben, aber das wird wieder nur Bibliotheken hinzufügen und Wünsche
erfüllen, die sich aus bestehenden Projekten ergeben.
Als Sprache für Neuentwicklungen wird dann wahrscheinlich etwas anderes
benutzt... ich glaube nicht, dass Java dann noch eine plattform für
spannende neue Konzepte bietet.
Mainstream-Sprachen halten sich inzwischen sehr lange, denke ich.
In vielen Industrie-Bereichen geht die Entwicklung mit Java gerade
erst los (Embedded-Systems, Mobile-Systems, Als leider sehr unschönes
Beispiel: Die Rüstungs- und Raumfahrindustrie tendiert dazu, von Ada
auf Java zu migrieren.)

Meiner Ansicht nach wird Java uns noch weitere 20 Jahre begleiten.


Viele Grüße,
Carl
Stefan Matthias Aust
2004-05-12 18:34:25 UTC
Permalink
Post by Carl Rosenberger
Du weist aber schon, wofür ich mir das Feature wünsche?
Ja.
Post by Carl Rosenberger
Ich will Datenbankabfragen auf Felder einschränken.
Die Frage ist natürlich, ob Felder - die eigentlich für jedes Objekt
Privatsache sein sollten - wirklich geeignet für DB-Anfragen sind.
Sollte man nicht lieber properties benutzen? Hat Java so nicht direkt,
aber doch über Beans und Getter...
Post by Carl Rosenberger
(1) Wie kann ich das refakturieren?
(2) Das ist aber nicht Compile-Time-gecheckt. Geht das irgendwie?
(3) Ich will die interne Implementation der Klasse nicht in meiner
Abfrage drin haben.
Was bedeutet denn 3? Das was ich oben anmerkte?
Post by Carl Rosenberger
Ich habe noch nicht damit gearbeitet aber ich denke auch, daß ich sie
nicht brauche. In der Regel weiß ich, was ich in Collections aufhebe
und so langsam ist man an das Casten schon gewöhnt und man kann sich
sogar mit Eclipse QuickFix das manuelle Tippen der Casts sparen.
Und genau das gilt auch für die Probleme, die du bei manuellem
Refactoring befürchtest. Ich behaupte, da machst du genauso selten
Fehler wie bei keinen Generics.

Übrigens: Ich will generics schon, denn sie machen den Code schicker.
Doch Fehler finden, das hat bislang noch nicht geklappt...

Die einzige Änderungen am Typsystem, die ich in dieser Beziehung für
interessant erachten würde, wäre der Verzicht darauf, dass null Element
jeden Typs ist.
Post by Carl Rosenberger
class Foo{
int barbarzargarnarharhar;
}
(1) Field f = Foo#barbarzargarnarharhar;
(2) Field f = Foo.class.getField("barbarzargarnarharhar");
Für Version 2 muß man den String komplett von Hand schreiben.
Wieso das? Beim Emacs drückst du einfach Meta-/ und er komplettiert das
Wort aus dem Quelltext. JEdit kann das mit Strg+B und Eclipse auch,
allerdings liegt diese Funktion per default auf keiner Taste.
Post by Carl Rosenberger
Bei Version 1 kann einem die IDE mit AutoKomplettierung helfen.
Bei 2. könnte sie das ebenfalls...
Post by Carl Rosenberger
Wenn man hunderttausend mal Version 1 mit Autokomplettierung
schreibt, macht man dabei keinen einzigen Fehler.
Doch. Die Fehlerwahrscheinlichkeit wird mit der Dauer sogar größer, da
du dich daran gewöhnst und nicht mehr nachschaust. Es gibt die Studie,
dass so Dialog die Fragen, "Willst du die Datei wirklich löschen"
tatsächlich eher stören als helfen. Der Benutzer weiss, dass der Dialog
kommt, und drückt automatisch ohne Nachdenken auf RETURN, um das Ja zu
bestätigen. Er dankt aber nicht mehr vor dem Löschen nach. Genauso
kann es dir passieren, dass du den falschen Text aus der Autokompletion
herauspickst, weil es sonst immer der erste war, jetzt nicht mehr und du
merkst das nicht.
Post by Carl Rosenberger
Zugegebermassen hast Du Recht, aber mit Deiner Argumentation negierst
Du den Vorteil von Compile-Time-Checks völlig.
Ich weiss. Ich halte das auch für einen sehr geringen Vorteil - und
allgemein nicht viel davon. Denn die Gefahr ist zu groß, dass man
tatsächlich glaubt, es läuft, nur weil es kompiliert.

Dabei kann ich auch in Java 1.5 mit -Xlint:all problemlos dies kompilieren:

Object o = "Hallo";
Integer i = (Integer) o;

Erst wenn casts verboten werden, und ich nur noch Class#cast benutzen
kann, wird es schwer. Dann müsste ich nämlich

Object o = "Hallo";
Integer i = Integer.class.cast(o);

schreiben und hier findet der Compiler zur Übersetzungszeit, dass ich
Müll mache. Leider findet zumindest die Beta1 obigen Fehler nicht.
Dabei wäre ich sofort bereit, untere Variante zu benutzen, wenn man mir
im Gegenzug verspricht, casts (für Objekttypen, für primitive Datentypen
hat die selbe Syntax ja bekoppterweise eine ganz andere Bedeutung der
Datenkonvertierung) aus der Sprache zu verbannen oder zumindest als
Warnung anzukreiden.
Post by Carl Rosenberger
Haben wir nicht vor drei Jahren ausgemacht, daß wir uns in
"fünf Jahren" etwas eigenes ausdenken? Ich fürchte, bei mir
wird es eher noch 10 Jahre dauern.
Du meinst, du willst noch 10 Jahre lang Java machen?
Post by Carl Rosenberger
O.K. einverstanden, das ist auch ein Argument.
Es würde der IDE recht schwer fallen, aus dem Kontext der Methode auf die
Klasse schliessen zu können, die gemeint ist. Man kann das sicher in
Eclipse einbauen, aber es ist nicht trivial.
Die IDE weiss bei jeder Methode, zu welcher Menge von Klassen sie gehört...
Post by Carl Rosenberger
Ich muß auch gestehen, mir ist sehr viel lieber, wenn das Eclipse-Team
das macht, als wenn ich aus meinem Umfeld sehen muß, wie das erledigt
wird.
PALs sind immer besser als eigene Probleme, ja...
Post by Carl Rosenberger
Mainstream-Sprachen halten sich inzwischen sehr lange, denke ich.
In vielen Industrie-Bereichen geht die Entwicklung mit Java gerade
erst los (Embedded-Systems, Mobile-Systems, Als leider sehr unschönes
Beispiel: Die Rüstungs- und Raumfahrindustrie tendiert dazu, von Ada
auf Java zu migrieren.)
Meiner Ansicht nach wird Java uns noch weitere 20 Jahre begleiten.
Mag sein, aber ob ich Java so lange begleite... ich befürchte, das wäre
mir zu langweilig. Und falls ich die Freiheit habe, auszusuchen, werde
ich bestimmt (sage ich zumindest heute) nicht noch 20 Jahre Java machen.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Jochen Theodorou
2004-05-12 19:39:37 UTC
Permalink
[...]
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Ich will Datenbankabfragen auf Felder einschränken.
Die Frage ist natürlich, ob Felder - die eigentlich für jedes Objekt
Privatsache sein sollten - wirklich geeignet für DB-Anfragen sind.
gut, wie mache ich dann abstrakt klar, dass man zum setzen eines Feldes
die und die Methode nutzen soll? Natürlich kann ich jetzt für jede
Methode eine Klasse bauen, die ein Interface implementiert, welches mir
das vernünftig ermöglicht... Aber das ist doch extremst unelegant...
nicht das Java besonders elegant wäre, aber wenn ich 20 solcher Klassen
brauche nur um 10 Properties zu lesen und zu schreiben... nö danke.
Also bleibt nur Reflection, und das RFE soll ja Reflection einfacher machen.

[...]
Post by Stefan Matthias Aust
Post by Carl Rosenberger
In der Regel weiß ich, was ich in Collections aufhebe
und so langsam ist man an das Casten schon gewöhnt und man kann sich
sogar mit Eclipse QuickFix das manuelle Tippen der Casts sparen.
Und genau das gilt auch für die Probleme, die du bei manuellem
Refactoring befürchtest. Ich behaupte, da machst du genauso selten
Fehler wie bei keinen Generics.
Dennoch... wenn man rein die Masse betrachtet.. Ich habe erst vor kurzem
an Code gearbeitet, wo ich mir generics gewünscht hätte. Es war eben
nicht mehr ganz klar, welcher Txp da am Ende rauskam... So viele
ClassCastException hatte ich in meinem ganzen Leben noch nicht produziert.

[...]
Post by Stefan Matthias Aust
Post by Carl Rosenberger
class Foo{
int barbarzargarnarharhar;
}
(1) Field f = Foo#barbarzargarnarharhar;
(2) Field f = Foo.class.getField("barbarzargarnarharhar");
Für Version 2 muß man den String komplett von Hand schreiben.
Wieso das? Beim Emacs drückst du einfach Meta-/ und er komplettiert das
Wort aus dem Quelltext. JEdit kann das mit Strg+B und Eclipse auch,
allerdings liegt diese Funktion per default auf keiner Taste.
Ja gut... und dann änderst du den Feldnamen und dann?
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Bei Version 1 kann einem die IDE mit AutoKomplettierung helfen.
Bei 2. könnte sie das ebenfalls...
Wie, bitte erklär es mir. Emacs komplettiert zwar aus dem Quelltext,
aber nur aus offenen Dateien. Lädst du 200 Dateien, nur damit du eine
Textvervollständigung nutzen kannst? Oder irre ich mich da?

[...]
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Zugegebermassen hast Du Recht, aber mit Deiner Argumentation negierst
Du den Vorteil von Compile-Time-Checks völlig.
Ich weiss. Ich halte das auch für einen sehr geringen Vorteil - und
allgemein nicht viel davon.
ich weiss, genauso wie ein statisches Typsystem, oder?
Post by Stefan Matthias Aust
Denn die Gefahr ist zu groß, dass man
tatsächlich glaubt, es läuft, nur weil es kompiliert.
Wer das glaubt hat noch nie an einem grösserem Projekt gearbeitet würde
ich mal sagen.
Post by Stefan Matthias Aust
Object o = "Hallo";
Integer i = (Integer) o;
Erst wenn casts verboten werden, und ich nur noch Class#cast benutzen
kann, wird es schwer. Dann müsste ich nämlich
Object o = "Hallo";
Integer i = Integer.class.cast(o);
schreiben und hier findet der Compiler zur Übersetzungszeit, dass ich
Müll mache.
Ein cast ist doch ein Hinweis für den Compiler, dass jenes Object
eigentlich einen anderen Typ hat. Wie soll mir da eine Funktion helfen?
Wenn (Integer) o suntactic sugar für Integer.class.cast(o) ist, dann
gibt es doch da keinen Unterschied, oder? Was du meinst ist wohl, dass
die Funktion cast den Rückgabetyp Integer hat. Dann kann man aber nur
eine solche Funktion haben... Das geht so in Java also nicht.
Post by Stefan Matthias Aust
Leider findet zumindest die Beta1 obigen Fehler nicht.
Ich finde dass der Compiler diese Fehler auch nicht finden muss. Er
könnte ihn allerdings finden.

Gruss theo
Stefan Matthias Aust
2004-05-12 19:53:17 UTC
Permalink
Post by Jochen Theodorou
gut, wie mache ich dann abstrakt klar, dass man zum setzen eines Feldes
die und die Methode nutzen soll? Natürlich kann ich jetzt für jede
Methode eine Klasse bauen, die ein Interface implementiert, welches mir
das vernünftig ermöglicht... Aber das ist doch extremst unelegant...
Reicht nicht ein Interface pro Domain-Klasse um die es geht? Ich denke,
man sollte gar nicht versuchen, Klassen persistent machen, sondern da
bei Interfaces bleiben... ich glaube, wir verstehen uns nicht.
Post by Jochen Theodorou
Dennoch... wenn man rein die Masse betrachtet.. Ich habe erst vor kurzem
an Code gearbeitet, wo ich mir generics gewünscht hätte.
Vor kurzem? Dann hättest du doch generics benutzen können? Oder war es
nicht so kurz?
Post by Jochen Theodorou
Es war eben
nicht mehr ganz klar, welcher Txp da am Ende rauskam... So viele
ClassCastException hatte ich in meinem ganzen Leben noch nicht produziert.
:) Okay, vielleicht habe ich nicht bedacht, dass manch Code gar
gräußlich ist. Aber ich hatte mir einfach 3 kleinere Projekte aus dem
Internet besorgt und generifiziert und dabei keine neuen Erkenntnisse
gewonnen.
Post by Jochen Theodorou
Ja gut... und dann änderst du den Feldnamen und dann?
Dann gibt es Fehler beim Ausführen der unit tests und ich korrigiere
diese. Das wolltest du doch hören, oder? :)
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Bei 2. könnte sie das ebenfalls...
Wie, bitte erklär es mir. Emacs komplettiert zwar aus dem Quelltext,
aber nur aus offenen Dateien. Lädst du 200 Dateien, nur damit du eine
Textvervollständigung nutzen kannst? Oder irre ich mich da?
Ja, wieso nicht? Wo ist das Problem? Wenn mein 1GB Hauptspeicher nicht
reicht, dann rüste ich nochmal 1GB nach... das sollte doch wohl das
kleinste Problem sein. Openoffice komplettiert beim Tippen ja auch
Worte, und das sogar Dokumentübergreifend. Da mache ich mir einfach ein
Dokument mit all den schweren Fachbegriffen drin auf und kann in meinem
jeweiligen Dokument bequem diese tippen. Finde ich praktisch.
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Denn die Gefahr ist zu groß, dass man tatsächlich glaubt, es läuft,
nur weil es kompiliert.
Wer das glaubt hat noch nie an einem grösserem Projekt gearbeitet würde
ich mal sagen.
Moment. Gerade da gilt meine Aussage: Nur weil's kompiliert, läuft das
noch lange nicht. Oder wolltest du genau das auch sagen?
Post by Jochen Theodorou
Ein cast ist doch ein Hinweis für den Compiler, dass jenes Object
eigentlich einen anderen Typ hat. Wie soll mir da eine Funktion helfen?
Tut es aufgrund von generics-Magie. Guck dir mal die Methode an. Denke
über den Typ Class<T> und die Signatur von cast() nach. Sehr schau
gemacht...
Post by Jochen Theodorou
Ich finde dass der Compiler diese Fehler auch nicht finden muss.
Ein statisches Typsystem, das diesen Namen verdient, muss diesen Fehler
finden!


bye
--
Stefan Matthias Aust // "I will whisper in a deaf ear
while I know you cannot speak" -DoD
Jochen Theodorou
2004-05-12 20:56:03 UTC
Permalink
Post by Stefan Matthias Aust
Post by Jochen Theodorou
gut, wie mache ich dann abstrakt klar, dass man zum setzen eines
Feldes die und die Methode nutzen soll? Natürlich kann ich jetzt für
jede Methode eine Klasse bauen, die ein Interface implementiert,
welches mir das vernünftig ermöglicht... Aber das ist doch extremst
unelegant...
Reicht nicht ein Interface pro Domain-Klasse um die es geht?
Kommt darauf an auf welchem Level der Abstraktion du operierst. Wenn du
ein interface vorraussetzt, dann auch eine gewisse Strukturierung.
Post by Stefan Matthias Aust
Ich denke,
man sollte gar nicht versuchen, Klassen persistent machen, sondern da
bei Interfaces bleiben... ich glaube, wir verstehen uns nicht.
mmmh... ein Beispiel...
http://groups.google.de/groups?selm=de/comp-lang-java/faq/115%40cscc.de
Ich wollte unbedingt ein PreparedStatement haben, dass ich erweitern
kann. Ohne Reflection geht das nicht. Und so kommt es, dass ich dann
solchen Code drin habe:

static {
try {
Class c = PreparedStatement.class;
addMethodFromClass(c, "setBoolean", Boolean.TYPE, "java.lang.Boolean");
addMethodFromClass(c, "setByte", Byte.TYPE, Byte.class);
addMethodFromClass(c, "setInt", Integer.TYPE, Integer.class);
addMethodFromClass(c, "setLong", Long.TYPE, Long.class);
addMethodFromClass(c, "setString", String.class, String.class);
addMethodFromClass(c, "setDouble", Double.TYPE, Double.class);
addMethodFromClass(c, "setFloat", Float.TYPE, Float.class);
addMethodFromClass(c, "setObject", Object.class, Object.class);
addMethodFromClass(c, "setShort", Short.TYPE, Short.class);

} catch (Exception e) {
e.printStackTrace();
}

private static void addMethodFromClass(Class c, String method, Class
type, Class key) {
try {
Method m = c.getMethod(method,new Class[] {Integer.TYPE,type});
methods.put(key, m);
} catch (Exception e) {
e.printStackTrace();
}
}

Wenn nun das RFE gelten würde hätte das folgende Auswirkung:

static {
methods.put(Boolean.class,
PreparedStatement#setBoolean(new Object[]{Integer.TYPE, Boolean.TYPE})
);
methods.put(Byte.class,
PreparedStatement#setByte(new Object[]{Integer.TYPE, Byte.TYPE})
);
methods.put(Integer.class,
PreparedStatement#setInt(new Object[]{Integer.TYPE, Integer.TYPE})
);
methods.put(Long.class,
PreparedStatement#setLong(new Object[]{Integer.TYPE, Long.TYPE})
);
methods.put(String.class,
PreparedStatement#setString(new Object[]{Integer.TYPE, String.class})
);
methods.put(Couble.class,
PreparedStatement#setDouble(new Object[]{Integer.Type, Double.TYPE})
);
methods.put(Float.class,
PreparedStatement#setFloat(new Object[]{Integer.Type, Float.TYPE})
);
methods.put(Object.class,
PreparedStatement#setObject(new Object[]{Integer.Type, Object.class})
);
methods.put(Short.class,
PreparedStatement#setShort(new Object[]{Integer.Type, Short.TYPE})
);
}

und hätte die Methode überhaupt nicht gebraucht. Ich würde Nummer 2
vorziehen.

Ganz ohne Reflection müsstest du um jede Methode eine Klasse bauen...

interface Setter{
void execute(int i, Object o);
}

class SetInt implements Setter{
void execute(int i, Object o) {
statement.setInt(i, (Integer) o);
}
}

und dass für jede Methode... dann brauchst du immer genau ein Exemplar
davon, das du nach obigem Muster in ein Hashtablepackst
Sprich, du simulierst Reflection höchst umständlich.
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Dennoch... wenn man rein die Masse betrachtet.. Ich habe erst vor
kurzem an Code gearbeitet, wo ich mir generics gewünscht hätte.
Vor kurzem? Dann hättest du doch generics benutzen können? Oder war es
nicht so kurz?
Zielplattform war 1.4, ausserdem war die Lib die ich benutzen musste
nicht von mir und nicht auf generics ausgelegt.
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Es war eben nicht mehr ganz klar, welcher Txp da am Ende rauskam... So
viele ClassCastException hatte ich in meinem ganzen Leben noch nicht
produziert.
:) Okay, vielleicht habe ich nicht bedacht, dass manch Code gar
gräußlich ist. Aber ich hatte mir einfach 3 kleinere Projekte aus dem
Internet besorgt und generifiziert und dabei keine neuen Erkenntnisse
gewonnen.
Also, bei JGraph hätte ich es schon vorgezogen generisch die Typen
festlegen zu können. Dort würde das echt was bringen glaube ich.
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Ja gut... und dann änderst du den Feldnamen und dann?
Dann gibt es Fehler beim Ausführen der unit tests und ich korrigiere
diese. Das wolltest du doch hören, oder? :)
Also, wenn man deine anderen Postings so kennt scheint das Einzige was
dich wirklich noch an Java bindet die Möglichkeit zu sein mit Eclipse zu
refactorieren ;)
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Bei 2. könnte sie das ebenfalls...
Wie, bitte erklär es mir. Emacs komplettiert zwar aus dem Quelltext,
aber nur aus offenen Dateien. Lädst du 200 Dateien, nur damit du eine
Textvervollständigung nutzen kannst? Oder irre ich mich da?
Ja, wieso nicht? Wo ist das Problem? Wenn mein 1GB Hauptspeicher nicht
reicht, dann rüste ich nochmal 1GB nach...
Tja, leider geht das bei meinem Computer nicht, der verträgt nur SDRAM
mit 66MHZ, das bekommt man heute nicht mehr... Achja, 1GB verträgt das
Board auch nicht.
Post by Stefan Matthias Aust
das sollte doch wohl das kleinste Problem sein.
Wenn du meinst...
Post by Stefan Matthias Aust
Openoffice komplettiert beim Tippen ja auch
Worte, und das sogar Dokumentübergreifend. Da mache ich mir einfach ein
Dokument mit all den schweren Fachbegriffen drin auf und kann in meinem
jeweiligen Dokument bequem diese tippen. Finde ich praktisch.
ähmm... schon, ja...ich will ja nicht behaupten dass das nicht unmöglich
ist zu implementieren, aber machen wird es in Eclipse wohl niemand.
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Denn die Gefahr ist zu groß, dass man tatsächlich glaubt, es läuft,
nur weil es kompiliert.
Wer das glaubt hat noch nie an einem grösserem Projekt gearbeitet
würde ich mal sagen.
Moment. Gerade da gilt meine Aussage: Nur weil's kompiliert, läuft das
noch lange nicht. Oder wolltest du genau das auch sagen?
Ja, ich wollte sagen: "wenn es kompiliert heißt das noch lange nicht daß
es auch läuft"
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Ein cast ist doch ein Hinweis für den Compiler, dass jenes Object
eigentlich einen anderen Typ hat. Wie soll mir da eine Funktion helfen?
Tut es aufgrund von generics-Magie. Guck dir mal die Methode an. Denke
über den Typ Class<T> und die Signatur von cast() nach. Sehr schau
gemacht...
Klär mich doch bitte mal auf. Schreib mir mal ein Beispiel, verwende
keinen nativen Code und auch bitte nicht den ()-Operator.

Oder meintest du das hier?

Class<T> {
static T cast(Object o) {
return (T) o;
}
}

Integer {
static class = new Class<Integer>();
}

aber dann compiliert das hier doch auch:

Object o = "Hallo";
Integer i = Integer.class.cast(o);


Also.. lass mich mal etwas Magie spüren ;)
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Ich finde dass der Compiler diese Fehler auch nicht finden muss.
Ein statisches Typsystem, das diesen Namen verdient, muss diesen Fehler
finden!
in diesem einfachen Fall könnte der Compiler das, ja, aber nciht im
Allgemeinen. Das bedeutet, du willst einen Aufwendigen check für etwas
das selten vorkommt? Oder ist es garnicht so selten wie ich glaube?
Einerseits wetterst du quasi ganz und gar gegen Codecompletion und dann
willst du sowas im Compiler...

Gruss theo
Stefan Matthias Aust
2004-05-13 10:33:37 UTC
Permalink
Post by Jochen Theodorou
static {
methods.put(Boolean.class,
PreparedStatement#setBoolean(new Object[]{Integer.TYPE, Boolean.TYPE})
);
Finde ich auch nicht einfacher. Müsste die Syntax außerdem nicht

PreparedStatement#setBoolean(int, boolean)

sein. So würde das meiner Meinung nach nur Sinn machen. Dann kommen
wir langsam dahin, dass ich Methoden einfach als Objekte benutzen kann.

Obige Variante finde ich sogar falsch. Denn das #set.. ist ein Literal,
in dem nicht einfach wieder ein Ausdruck (new Object...) stehen kann.
Post by Jochen Theodorou
Also, bei JGraph hätte ich es schon vorgezogen generisch die Typen
festlegen zu können. Dort würde das echt was bringen glaube ich.
Echt? Hast du mal ein Beispiel?
Post by Jochen Theodorou
Also, wenn man deine anderen Postings so kennt scheint das Einzige was
dich wirklich noch an Java bindet die Möglichkeit zu sein mit Eclipse zu
refactorieren ;)
Jepp. Und natürlich das liebe Geld :)
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Tut es aufgrund von generics-Magie.
Ich nehme alles wieder zurück. Ich irrte.
Post by Jochen Theodorou
in diesem einfachen Fall könnte der Compiler das, ja, aber nciht im
Allgemeinen.
Dann gehören die allgemeinen Fälle aus der Sprache verbannt.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Jochen Theodorou
2004-05-13 15:55:38 UTC
Permalink
Post by Stefan Matthias Aust
Post by Jochen Theodorou
static {
methods.put(Boolean.class,
PreparedStatement#setBoolean(new Object[]{Integer.TYPE,
Boolean.TYPE})
);
Finde ich auch nicht einfacher. Müsste die Syntax außerdem nicht
PreparedStatement#setBoolean(int, boolean)
hast recht ;) Das macht hier irgendwie mehr Sinn. Die Leute wollten
JGraph nicht auf was reduzieren, dass die Interfaces implementiert.
Diese Interfaces waren nur zur Typsicherheit und für die Funktionalität
eigentlich nicht notwendig. Wenn man jetzt Generics nimmt, dann kann man
aber die Typsicherheit ein Stück weit wieder herstellen, ohne
gleichzeitig die Allgemeinheit einzuschränken.

[...]
Post by Stefan Matthias Aust
Post by Jochen Theodorou
Also, bei JGraph hätte ich es schon vorgezogen generisch die Typen
festlegen zu können. Dort würde das echt was bringen glaube ich.
Echt? Hast du mal ein Beispiel?
mmmh... schwer... wie soll ich das jetzt erklären ohne eine Einführung
in JGraph zu geben?

[...]
Post by Stefan Matthias Aust
Post by Jochen Theodorou
in diesem einfachen Fall könnte der Compiler das, ja, aber nciht im
Allgemeinen.
Dann gehören die allgemeinen Fälle aus der Sprache verbannt.
Nun, die wird es immer geben, oder? Ich meine, der Compiler kann ja
nicht das Programm führ mich schreiben;)

Gruss theo
Carl Rosenberger
2004-05-12 21:07:31 UTC
Permalink
Post by Stefan Matthias Aust
Die Frage ist natürlich, ob Felder - die eigentlich für jedes Objekt
Privatsache sein sollten - wirklich geeignet für DB-Anfragen sind.
Sollte man nicht lieber properties benutzen?
Du hast völlig Recht, man sollte, wenn das möglich ist.

Es gibt aber Downsides, die ich in meinem letzten Posting
schon angedeutet habe. Man hat zwei Möglichkeiten:

(1) Jedes Objekt wird während der Evaluierung der Abfrage
instantiiert. Das kostet im Vergleich zur Evaluierung einzelner
unabhängier Feldwerte sehr viel Zeit. db4o 3.0 instantiiert noch
nicht einmal Strings, um sie zu vergleichen. Stattdessen wird bei
Vergleichen auf byte-array Ebene gearbeitet.
Je nachdem wie weit eine Methode verzweigt, kann eine ganze Menge
passieren. Wie Du weißt, werden Feldzugriffe bei der Arbeit mit
db4o nicht durch die Datenbank umgeleitetet, es gibt stattdessen
ein "Tiefen"-Konzept. Das muß gegebenenfalls für Anwendungsfälle
von Hand eingestellt werden, damit man nicht zu viel (langsam) oder
zu wenig (NPE, falsche Ergebnisse) instantiiert.

(2) Die Ergebnisse der für Abfragen benötigte Methodenaufrufe
werden beim Speichern von Objekten mitgespeichert, idealerweise
indiziert. Dann müssen aber diese Indexwerte bei einem Umbau der
Implementation mit einem Lauf über alle Objekte alle neu
gespeichert werden.


Das Feature, Methodenergebnisse in Abfragen einzubauen, wird aber
in der Tat häufig nachgefragt, es ist sehr einfach zu implementieren,
also wird es in naher Zukunft eingebaut.

Im Moment kann man zwar Abfragen auch schon durch Methodenergebnisse
einschränken (Evaluation/Candidate callback) aber indiziert wird das
ganz anders fliegen.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
(3) Ich will die interne Implementation der Klasse nicht in meiner
Abfrage drin haben.
Was bedeutet denn 3? Das was ich oben anmerkte?
Ja, genau.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Ich habe noch nicht damit gearbeitet aber ich denke auch, daß ich sie
nicht brauche. In der Regel weiß ich, was ich in Collections aufhebe
und so langsam ist man an das Casten schon gewöhnt und man kann sich
sogar mit Eclipse QuickFix das manuelle Tippen der Casts sparen.
Und genau das gilt auch für die Probleme, die du bei manuellem
Refactoring befürchtest. Ich behaupte, da machst du genauso selten
Fehler wie bei keinen Generics.
Ich will aber keine manuellen Refactorings. Ich baue oft und gerne
um und ich will, daß unsere Kunden genauso einfach ein Feld mit
einem automatischen Refactoring umbenennen können wie ich, ohne
weitere Anpassung von Abfragen.

Ich würde mir auch wünschen, daß man einen Obfuscator über die
Applikation laufen lassen kann, ohne Abfragen zu zerschiessen.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
(2) Field f = Foo.class.getField("barbarzargarnarharhar");
Für Version 2 muß man den String komplett von Hand schreiben.
Wieso das? Beim Emacs drückst du einfach Meta-/ und er komplettiert das
Wort aus dem Quelltext. JEdit kann das mit Strg+B und Eclipse auch,
allerdings liegt diese Funktion per default auf keiner Taste.
Das ist ein guter Tipp. Kannst Du mir bitte sagen, wo ich diese
Funktionalität in Eclipse finde?
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Wenn man hunderttausend mal Version 1 mit Autokomplettierung
schreibt, macht man dabei keinen einzigen Fehler.
Doch.
Na gut, hier kommen wir nicht weiter. Ich bin da einfach anderer
Meinung, vielleicht arbeiten wir beide einfach ganz anders.
Post by Stefan Matthias Aust
Object o = "Hallo";
Integer i = (Integer) o;
Ich verwende Variablen vom Typ "Object" eigentlich so gut wie nie.
Du?
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Haben wir nicht vor drei Jahren ausgemacht, daß wir uns in
"fünf Jahren" etwas eigenes ausdenken? Ich fürchte, bei mir
wird es eher noch 10 Jahre dauern.
Du meinst, du willst noch 10 Jahre lang Java machen?
Ich denke, ich muß mein Baby begleiten, bis es ganz erwachsen ist
und ich rechne heute damit, daß das so lange dauert.

Woran ich am allerallerliebsten arbeiten würde, steht erstmal
nicht zur Debatte aber ein großes Problem ist das nicht. Ich
liebe meine Arbeit so wie sie ist.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Es würde der IDE recht schwer fallen, aus dem Kontext der Methode auf die
Klasse schliessen zu können, die gemeint ist. Man kann das sicher in
Eclipse einbauen, aber es ist nicht trivial.
Die IDE weiss bei jeder Methode, zu welcher Menge von Klassen sie gehört...
Gut, sie müßte sich aber in diesem Fall auch ansehen, wie eine
Abfrage vorher nach Klasse eingeschränkt worden ist. Das muß
nicht in der Zeile davor stehen, der Code kann auch modular
aufgebaut sein, dann befindet sich die zugehörige Klasse im
Stack vielleicht 7 Schritte weiter oben und vielleicht gibt es
ein Dutzend verschiedener Aufrufe.
Post by Stefan Matthias Aust
Post by Carl Rosenberger
Meiner Ansicht nach wird Java uns noch weitere 20 Jahre begleiten.
Mag sein, aber ob ich Java so lange begleite... ich befürchte, das wäre
mir zu langweilig. Und falls ich die Freiheit habe, auszusuchen, werde
ich bestimmt (sage ich zumindest heute) nicht noch 20 Jahre Java machen.
Ich habe vielleicht diese Freiheit nicht. Dafür, daß mir nicht langweilig
wird, versuche ich selbst zu sorgen.


Viele Grüße,
Carl
Jochen Theodorou
2004-06-02 16:41:43 UTC
Permalink
Post by Carl Rosenberger
Hallo,
um folgenden RFE eingetragen zu bekommen, habe ich 2 Jahre
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Ich würde mich sehr über rege Unterstützung durch Eure Stimmen
freuen. Ich würde dieses Feature lieben.
Sorry, wenn ich den alten Thread nochmal anwärme, aber hast du schonmal
darüber nachgedacht welche Vorteile JDO von dieser Syntax hätte?
Vielleicht findet man dann auch Unterstützung durch das JDO-Lager...
oder bei den Leuten von Hibernate.

Gruss theo
Carl Rosenberger
2004-06-03 20:17:03 UTC
Permalink
Post by Jochen Theodorou
Post by Carl Rosenberger
um folgenden RFE eingetragen zu bekommen, habe ich 2 Jahre
http://developer.java.sun.com/developer/bugParade/bugs/5043025.html
Ich würde mich sehr über rege Unterstützung durch Eure Stimmen
freuen. Ich würde dieses Feature lieben.
Sorry, wenn ich den alten Thread nochmal anwärme, aber hast du schonmal
darüber nachgedacht welche Vorteile JDO von dieser Syntax hätte?
Vielen Dank, daß Du das nochmal aufgreifst, Theo, vielleicht findet
sich ja nochmal jemand, der eine Stimme leihen kann.



JDO hätte keine Vorteile davon. Bei JDO arbeitest Du mit komplett mit
Strings, nicht nur bei Feldnamen sondern bei der *ganzen* Einschränkung
der Abfrage, die man bei JDO "Filter" nennt. Hier ein Beispiel:

Query q = pm.newQuery(Person.class);
q.declareVariables("tutorial.Book b; tutorial.Person p1; tutorial.Person p2");
String params = "String pTitle, String pPatrick, String pLinskey, " +
"String pCarl, String pRosenberger";
q.declareParameters(params);
String filter = "b.title.matches(pTitle) "
+ "&& ((p1 == this && b.authors.contains(p1) "
+ "&& p1.firstName == pPatrick "
+ "&& p1.lastName == pLinskey) "
+ "|| (p2 == this && b.authors.contains(p2) "
+ "&& p2.firstName == pCarl "
+ "&& p2.lastName == pRosenberger ))";
q.setFilter(filter);


...no comment...
Post by Jochen Theodorou
Vielleicht findet man dann auch Unterstützung durch das JDO-Lager...
oder bei den Leuten von Hibernate.
Aus dem Hibernate-Lager könnte es durchaus Unterstützung geben.

Zu den Criteria-Queries würde eine Einschränkung direkt über ein Feld
einer Klasse sehr gut passen:

http://www.hibernate.org/hib_docs/reference/en/html/querycriteria.html

Christian Bauer, liest Du mit? Kann man von Eurer Community Unterstützung
für typsichere Abfragen bekommen?


Mir gefällt der Ansatz von Hibernate für Criteria-Queries ausgesprochen
gut. Es liest sich spätestens mit static imports deutlich eleganter
als S.O.D.A.
Allerdings gibt es einen entschiedenen Schwachpunkt gegenüber S.O.D.A.:
Der Ansatz von Hibernate sieht nicht vor, bei komplexeren Objekten,
die man "by Example" einbaut (12.6), gezielt für einzelne Felder zu
bestimmen, wie sie gegen die Datenbank evaluiert werden sollen
(like, ignorecase, greater ....).
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Lesen Sie weiter auf narkive:
Loading...