Zitat von Wosi:

Unter Delphi wird es sich dann wohl weiterhin wie in den neunziger Jahren anfühlen, wenn man mit Fremdbibliotheken arbeitet.

Wenn du mit neunziger Jahre meinst, dass man sich darauf recht gut verlassen kann, dass die Projekte auch gepflegt und für neuere Versionen angepasst werden, bin ich voll dafür.

Was nützt es mir, wenn ich zwar alles abrufen kann, aber wie bei Torry tausende Leichen drin habe, die schon seit X Versionen nicht mehr funktionieren. Oder wenn ich eine Komponente für XE9 downloaden kann, diese aber für XE10 plötzlich nicht mehr verfügbar ist, weil sie niemand dafür angepasst hat.
Weniger ist an der Stelle (finde ich) eindeutig mehr...

Zitat von Wosi:

Castalia wirkt reingeklatscht. [..] Die "Extract-Method"-Funktion produziert weiterhin Müll. Was bringt mir eine Prozedur mit einem Var-Parameter?

Da muss ich leider zustimmen. Nachdem ich es mittlerweile ausprobiert habe, ist es qualitativ leider nicht besser als das integrierte Refactoring, im Gegenteil, es funktioniert sogar noch schlechter. Ich dachte vorher nicht, dass das möglich sei...
In einem Projekt mit nicht einmal 29.000 Zeilen...
"Castalia exceeded its allowed memory threshold for parse trees"
"No current file found. Prepare for an EIndexOutOfBounds error."
Und dann Schutzverletzung...

Aber schlimmer noch:
Im Gegensatz zum internen Refactoring wurde das Refactoring hier versucht trotzdem durchzuziehen. Teilweise werden Extraktionsmethoden erstellt, bei denen konstante Werte als var-Parameter weitergegeben werden, teilweise wird der extrahierte Code einfach ein paar Zeilen darüber in die gleiche Methode an zufälliger Stelle eingefügt (z.B. nach dem Semikolon einer SQL-Anweisung innerhalb eines Strings!!) und die Parameter blieben leer, ...

Beim "Surround with..." wird Code erzeugt, bei dem die Einrückung nicht stimmt, manchmal lässt sich die Aktion auch nicht per Strg + Z rückgängig machen, teilweise wird ein end zu wenig eingefügt, ...

Beim Methode umbenennen:
"No current file found. Prepare for an EIndexOutOfBounds error."
Schutzverletzung...

Ich dachte dann das läge eventuell am Projekt, aber das gleiche passiert bei zwei anderen ähnlich großen Projekten auch. Sorry, aber ich habe immer wieder Positives zu Castalia gehört. Das kann ich leider absolut nicht nachvollziehen, ich bin nur froh, dass wir dafür vor der Integration in Delphi kein Geld ausgegeben haben.

Man nehme ein Manifest, dass die Delphi-Version angibt (dann fliegen bei neuen Versionen automatisch die nicht gepflegten Komponenten in der Auswahl raus), dann einen Download-Counter und auch gerne noch ein Sterne-System. Und fertig ist ein System, dass sich selbst halbwegs aktuell hält, einen Indikator für Qualität hat und trotzdem mit Fremdpackages bestückt werden kann.

Bei PHP gibt es nur noch Composer / Packagist. Wenn was nicht auf der Plattform vorhanden ist, wird es schlicht nicht mehr verwendet. Da kann eine neue Bibliothek noch so gut sein. Im Frontend-Bereich läuft alles über Bower. Bei Node ist npm ein absolutes Muss.

Zitat von mquadrat:

[...] Bei PHP gibt es nur noch Composer / Packagist. Wenn was nicht auf der Plattform vorhanden ist, wird es schlicht nicht mehr verwendet. Da kann eine neue Bibliothek noch so gut sein. Im Frontend-Bereich läuft alles über Bower. Bei Node ist npm ein absolutes Muss.

Zitat von jaenicke:

Zitat von Wosi:

Unter Delphi wird es sich dann wohl weiterhin wie in den neunziger Jahren anfühlen, wenn man mit Fremdbibliotheken arbeitet.

Wenn du mit neunziger Jahre meinst, dass man sich darauf recht gut verlassen kann, dass die Projekte auch gepflegt und für neuere Versionen angepasst werden, bin ich voll dafür.

Was nützt es mir, wenn ich zwar alles abrufen kann, aber wie bei Torry tausende Leichen drin habe, die schon seit X Versionen nicht mehr funktionieren. Oder wenn ich eine Komponente für XE9 downloaden kann, diese aber für XE10 plötzlich nicht mehr verfügbar ist, weil sie niemand dafür angepasst hat.
Weniger ist an der Stelle (finde ich) eindeutig mehr...

Wie von mquadrat bereits angedeutet kann man es über Manifest-Dateien sicherstellen, dass nur die Komponenten angeboten werden, die mit der eingesetzten Delphi-Version funktionieren. Ebenso lässt sich über einen Download-Zähler und ein Bewertungssystem einiges an Frust ersparen, wenn man schon vor dem Download sieht, dass eine Komponente in zwei Jahren nur zehn mal heruntergeladen wurde.

Für den NuGet-Manager kann jeder Pakete hinzufügen und es funktioniert hervorragend. Ein Github-Repository kann automatisch mit NuGet synchronisiert werden und bleibt so stets aktuell. Als NuGet-User kann ich in meinem Projekt nach Updates suchen und erhalte Informationen zu allen eingesetzten Fremdbibliotheken. Der Wartungsaufwand ist gering. Wenn ein Paket nicht mehr passt oder fehlerhaft ist, finde ich für viele Aufgaben schnell eine passende Alternative.
In meinen C#-Projekten setze ich daher viel mehr fremden Code ein als in Delphi. Cryptographie, JSON-Serialisierung, Anbindung an diverse REST-Services, GUI-Komponenten etc. erhalte ich per Knopfdruck genauso wie die dazugehörigen Aktualisierungen.
Bei Delphi muss ich wie in den neunziger Jahren und den frühen zweitausendern auch weiterhin regelmäßig die Projektseiten der eingesetzten Fremdkomponenten abklappern. Wenn eine Bibliothek nicht mehr weiterentwickelt wird, beginnt die große Suche nach Alternativen in diversen Delphi-Foren und auf Stackoverflow. Das ist mühselig und führt häufig genug dazu, dass in Delphi-Projekten möglichst wenig Fremdsource eingesetzt wird und das Entwicklerteam folglich Dinge implementieren muss, die tausende andere Entwickler bereits vor Jahren geschrieben haben. Ja, es hat auch Vorteile wenn ein Team allen genutzen Source selbst geschrieben hat. Aber mit "Rapid Application Development" hat das nichts zu tun. RAD war die große Stärke von Delphi in seiner Hochzeit. Damals benötigte man für RAD nur einen UI-Designer in der IDE. Heute ist ein UI-Designer vernachlässigbar geworden. Durch automatisches Layouting lassen sich schöne GUIs auch schnell im Code schreiben.

Heute geht es bei RAD eher darum
- bestehende ausgereifte Komponenten schnell und zuverlässig einsetzen zu können
- Code vernünfitg refactoren zu können
- Schnell durch große Projekte zu navigieren (Wo wird Klasse XY verwendet? Wer ruft Funktion x() auf? Wer implementiert Interface I? etc.)
- Schnell sehen können, ob und wo ein Unit-Test fehlschlägt und welche Codezeilen gar nicht getestet werden

In all diesen Disziplinen hinkt auch Delphi XE8 der Konkurrenz weit hinterher. Mit RAD hat das nichts mehr zu tun. Für eine marktreife Applikation (beginnend auf der grünen Wiese) brauche ich mit Delphi aufgrund der oben genannten Punkte heute erheblich länger als mit C# oder Java. Wo ist eigentlich das Alleinstellungsmerkmal von Delphi geblieben? Was ist das große Argument gegenüber C++, C# oder Java? RAD ist es seit einigen Jahren nicht mehr.

Mit GetIt könnten sie zumindest ein bisschen in Richtung RAD rudern aber daran haben sie offenbar kein Interesse.

Zitat von Stevie:

Zitat von Wosi:

Ich hoffte es kommt endlich ein Testrunner, der in die IDE integriert ist und vielleicht eine CodeCoverage-Analyse für meine Testfälle.

An dieser Stelle möchte ich dich mal auf TestInsight verweisen (XE8 Support ist in der nächsten Version in den kommenden Wochen).

Danke für den Link. TestInsight habe ich kurz mit XE6 angetestet als ich auf DelphiFeeds davon erfahren habe. Innerhalb von zwanzig Minuten habe ich es nicht ans Laufen gebracht und wieder entfernt. Vielleicht gebe ich dem Projekt in Zukunft noch mal eine Chance. Die Idee hinter dem Projekt halte ich jedenfalls für richtig.

Praktisch wäre es ja, wenn man mehrere Quellen verwenden könnte,

Für Firmen wäre es bestimmt interessant, wenn sie so unter ihren Entwicklern die hauseigenen Komponenten ebenso verteilen könnten,
bzw. man selber so sein eigenes Zeugs zwischen den eigenen Rechnern/Schlepptops/usw..

Zitat von himitsu:

Für Firmen wäre es bestimmt interessant, wenn sie so unter ihren Entwicklern die hauseigenen Komponenten ebenso verteilen könnten,
bzw. man selber so sein eigenes Zeugs zwischen den eigenen Rechnern/Schlepptops/usw..

Auscheck CVS, Batch-Datei ausführen und dann die compilieren dcps in der IDE registrieren. So läuft das bei uns (Ok. die Batch-Datei hat zu D6-Zeiten einiges Gehirnzellen vernichtet. Mit MSBuild ist das aber schnell erledigt). Wie soll die IDE-Lösung funktionieren wenn man wegen Bugfixing diverese ältere Stände von Komponenten benötigt?

Kann das GetIT denn nicht mit Versionsständen der Komponenten umgehen?
Alleine für die Unterstützung von mehr, als nur der letzten/aktuellsten IDE, müsste es sowas ja geben.

Und außerdem solltet ihr lieber mehr Zeit in die Erfindung neuer Bugs investieren und benennt die Alten einfach in "Feature" um.
(hast du denn nix von Emba gelernt? )

Zitat von himitsu:

Kann das GetIT denn nicht mit Versionsständen der Komponenten umgehen?

Und wenn du in stand 1.1.20 für deine Programmversion 2.4.5 selbst einen fix gemacht hast der erst in 1.1.22 in die Komponente eingeflossen ist...

Von madExcept gibt es nun auch eine XE8-kompatible Version.

http://forum.madshi.net/viewtopic.php?f=11&t=27988

Der Download ist noch als "beta" gekennzeichnet, in früheren Fällen haben sich diese jedoch als äußerst stabil erwiesen.
(Und da auch in diesem Release im Kontext des Win32-/Win64-Compilers keine größeren Änderungen stattfanden, wird man wohl mit Zuversicht auf die o.g. Beta-Version schauen können.)