Slyh: Eigene Klassen einbinden

Beitrag lesen

Hallo,

Nur wenn man seine Gehirn vorhin mit einer grauenvollen Sprache[tm]
wie C++ oder Perl gequält hat.

NACK. C++ kann ich nicht, Perl habe ich schon lange nicht mehr angefasst. Die Vorgängersprache war Python.

OK, Python ist meiner Meinung nach etwas weniger grauenvoll als die
anderen genannten. So richtig kann ich das mangels wirklicher
Erfahrung aber nicht beurteilen.

Aber meine Polemik von oben ist sowieso nicht kommentierungswürdig,
eigentlich. *g*

Weder ziemlich alles, noch viel; aber eine Menge um einiges.

Das hast du schön gesagt. :)

Nur ist bis zu diesem Moment der Initialaufwand einfach extrem hoch. Danach geht es - aber ich rede hier eben nur vom Einstieg.

Auch hier erstmal ein ACK.

Ich habe mich schon öfter gefragt, wie ich Java empfunden hätte, wäre
ich damals nicht so auf C++ fixiert gewesen, obwohl ich es selbst
kaum konnte. Ich fand an Java alles schlimm, weil ich vorher Pascal
und Assembler gewohnt war, und daher dann auch das Pointer-Konzept
und das eigene Aufräumen im Destruktor von C++ etc. ganz toll fand.
Sowas selbst machen zu müssen, erinnert mich jetzt, rückblickend an
Selbstgeißelung. :-)

Einige meiner Kommilitonen haben C++ und Java zur gleichen Zeit
gelernt, und waren von Java begeistert, während sie C++ gehasst
haben. Bei mir war es umgekehrt. Erst viel später wurden mir die
Vorteile von Java klar.

Daher meine Aussage von oben, daß man Java am Anfang nur dann als
komplex empfindet, wenn man vorher eine andere Sprache verwendet hat,
bei der man evtl. mehr selbst machen mußte. (Im Falle von Python
mußte man hingegen vermutlich weniger machen. Das Resultat ist
dasselbe.)
Ich könnte mit meiner Einschätzung völlig falsch liegen...

Zustimmung. Wobei natürlich die Frage gestellt werden darf, woher die IDE denn die Doku kennen soll. Die meisten werden aus dem Quellcode erzeugt ... :-)

Ja, genau. Da für viele Quellen aber bereits Javadoc existiert, wäre
es wünschenswert, wenn aus diesem wieder eine für die IDE lesbare
Dokumentation im eigenen Format generiert werden könnte.
Später, wenn sich das Format etabliert hätte, wäre es natürlich
wünschenswert, wenn es gleich zusammen mit der (Closed-Source-)Software
ausgeliefert werden würde.

In Visual Studio ist das sehr viel schöner gelöst.
Dort reicht ein Druck auf F1, und schon ist man bei der Doku.

Auch von Dingen, die bei der Auslieferung von VS noch nicht bekannt waren?

Soweit ich weiß, ja. Leg mich aber nicht drauf fest. Hier gibt es
sicherlich Teilnehmer, die mit VS mehr (und aktuellere) Erfahrungen
haben.
Ich weiß, daß man aus Quellen irgendwelche Dateien generieren kann,
die sich dann in VS einbinden lassen. Ich bilde mir ein, daß dort
(auch?) die Doku enthalten ist.
Aber, wie gesagt, ich bin mir diesbezüglich nicht sehr sicher.

Es sollte einen Zurückübersetzer geben, der aus dem Javadoc-HTML ein
(gerne auch binäres) Format erzeugt, das vollständig integriert in
der IDE verwendet werden kann.

Auch dazu muss die Doku zunächst einmal bekannt sein. Nur woher? Die Einbindung irgend einen JAR-Files mit diversen CLASS-Dateien lässt noch lange nicht darauf schließen, wo die Verwendung dokumentiert ist - bzw. ob überhaupt.

Dafür muß eine Konvention existieren, klar. Aber wofür gibt es denn
die Manifest-Datei? Dort ließe sich doch eine Dokumentations-Datei
im JAR referenzieren.
Für einzelne Class-Dateien muß dann eben die IDE die Zuordnung
ermöglichen. So handhabt Eclipse dies ja auch heute schon, wenn man
die Sourcen an eine JAR-Datei "bindet".

Soweit zumindest meine Idee.
Vielleicht sollte ich dafür ein Eclipse-Plugin entwickeln... ;)

[Doku im externen Browser vermeiden]

Ja: Quellcode suchen! ;-)

Ich wußte, daß du das sagen würdest! ;-)

Bei uns klappt das (meistens), weil wir gewöhnlich nur Projekte verwenden, deren Quellcode uns zur Verfügung steht; sei es nun wegen Open Source oder durch Einkauf. Trotzdem habe ich schon oft genug überlegt, ob ich jetzt wirklich wieder ein externes Projekt auschecken möchte oder es mir doch antue, die Doku im Netz zu suchen. Schön ist es nicht.

Du meinst, weil das dann bei einem Full (Re)build wieder alles
mitkompiliert werden muß? Ja, das ist wirklich ein Nachteil. (Ich wüßte
jetzt spontan nicht mal, ob man einzelne Projekte aus dem Build-
Vorgang ausschließen kann, und trotzdem noch die Quellen zur
Dokumentation verwenden kann.)
Oder dauert es dir einfach zu lange, das Projekt auszuchecken, wenn
du nur schnell was nachschauen magst?

Ich hoffe, dass es nicht daran liegt, dass unsere Projekte komplizierter sind, sondern daran, dass Du einfach besser bist

Natürlich liegt es einzig und alleine daran! ;-)

Gruß
Slyh