DeHL Entwicklung eingestellt

[mjustin]

Die Projektseite http://code.google.com/p/delphilhlplib/ sagt:

Zitat:

DeHL is discontinued. You can reuse parts of this project for whatever particular needs you have. The source code is BSD licensed.

In seinem Blog (http://alex.ciobanu.org/) schreibt der Entwickler am 3. Januar 2012:

Zitat:

DeHL — A collection of code built around the concept of “type objects”. Unfortunately, DeHL only stirred some architectural interest in the Delphi community. It did not actually attract many active users or contributors. ... But, unless someone steps up and takes over, DeHL is effectively dead.

[Insider2004]

Das wundert mich jetzt nicht. DEHL läuft nur mit den neuen Delphi-Compilern und ist ziemlich kompliziert. Das widerspricht dem Pascal-anstatz. Die neuen Delphi-Sprachfeatures (anonyme Methoden etc.) haben sich bisher sowieso weniger durchgesetzt. Der Pascal-Programmierer liebt es halt einfach.

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1147093)

Die neuen Delphi-Sprachfeatures (anonyme Methoden etc.) haben sich bisher sowieso weniger durchgesetzt. Der Pascal-Programmierer liebt es halt einfach.

Gerade diese Features machen es ja sehr viel einfacher. Theoretisch zumindest...

Das Problem war nur, dass es relativ viele Bugs gab, z.B. dass in anonymen Methoden als Parameter bei XE generell die erste Ebene der Syntaxvervollständigung nicht funktionierte. Viele solcher Probleme sind aber bei XE2 behoben, so auch dieses.

Zumindest in unseren Quelltexten nutzen wir seit XE dennoch häufig Generics, anonyme Methoden, die aktuellen Rtti-Features, ...
Und wenn ich so die Posts von himitsu und anderen lese, sieht das bei anderen ja wohl auch ähnlich aus. ;-)

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1147097)

Das Problem war nur, dass es relativ viele Bugs gab, z.B. dass in anonymen Methoden als Parameter bei XE generell die erste Ebene der Syntaxvervollständigung nicht funktionierte. Viele solcher Probleme sind aber bei XE2 behoben, so auch dieses.

Für Komponentenhersteller wird aber eher das Problem bestehen das sie noch bis D6/7 dies Sammlungen anbieten.
Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Zitat:

Zitat von jaenicke (Beitrag 1147097)

..., die aktuellen Rtti-Features, ...

Diese erweiterte Rtti hat aber den Nachteil die Exe's riesig werden zu lassen :-(

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Für Komponentenhersteller wird aber eher das Problem bestehen das sie noch bis D6/7 dies Sammlungen anbieten.
Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Das sehe ich z.B. als ein großes Manko an!

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Diese erweiterte Rtti hat aber den Nachteil die Exe's riesig werden zu lassen :-(

Na und? Die Größe einer Exe-Datei ist doch sowas von egal, wenn ich damit im Gegenzug einen deutlichen Programmiervorteil erreichen kann. Die Zeiten von 640kB Hauptspeicher sind doch lange vorbei.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1147125)

Das sehe ich z.B. als ein großes Manko an!

Das die Komponentenanbieter das so machen, oder was meinst du damit genau?

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Na und? Die Größe einer Exe-Datei ist doch sowas von egal, wenn ich damit im Gegenzug einen deutlichen Programmiervorteil erreichen kann. Die Zeiten von 640kB Hauptspeicher sind doch lange vorbei.

Unsere D6-Exe ist 12-15 MB groß. Eine 50 MB Exe wäre nicht gerade von Vorteil (konnte bisher noch nicht das Hauptprogramm erfolgreich mit XE2 compilieren um den genauen Großenzuwachs mit und ohne Extended RTTI zu sehen

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Für Komponentenhersteller wird aber eher das Problem bestehen das sie noch bis D6/7 dies Sammlungen anbieten.
Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Wenn sich die Hersteller den Produktivitätsverlust leisten können und wollen ist ja alles ok. Schlecht ist nur, dass die dadurch entstehenden Entwicklungskosten sich nicht in den Versionen für die alten Delphiversionen wiederspiegeln, sondern meistens auf alle Käufer umgelegt werden...

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147127)

Zitat:

Zitat von Uwe Raabe (Beitrag 1147125)

Das sehe ich z.B. als ein großes Manko an!

Das die Komponentenanbieter das so machen, oder was meinst du damit genau?

Genau! Wenn sie es denn so machen. Es gibt schon ein paar Bibliotheken, die die neuen Features nutzen und somit auch nur mit den neuen Delphi-Versionen verwendet werden können. So ist z.B. Asphyre Sphinx in der neuen Version nur für XE2 verfügbar - und das ist auch gut so! Wer unbedingt auf älteren Delphi-Versionen entwickeln will, kann ja dazu auch die älteren Versionen der Bibliotheken nehmen. Neuentwicklungen sollte man eh nicht mit veralteten Werkzeugen ausbremsen - meine Meinung.

Die Krux liegt m.E. in der Gepflogenheit vieler Entwickler, die neuen Features oder Vorgaben neuer Versionen sozusagen mit "einzupatchen", anstatt direkt darauf aufzubauen ("deprecated" Warnungen beim Compileren). Wenn denn unbedingt ältere Versionen unterstützt werden müssen, dann muss man eben diese "einpatchen", über IFDEF anderen Code ausführen oder bestimmte Features eben dort ganz weglassen. Dann sieht man auch sofort, welche Versionen zu aufwändig mitzuziehen sind, und gibt deren Support vielleicht eher auf. Als Ergebnis hätte man wesentlich besser auf neue Versionen abgestimmte Bibliotheken. Auf der anderen Seite könnte das auch den Druck auf die Verwender älterer Versionen erhöhen, endlich ein neues Delphi zu erwerben und auch einzusetzen.

Natürlich ist das jetzt meine reine Entwicklersicht auf die Dinge - kaufmännisch mag es da noch andere Kriterien geben, auf die ich in meiner Betrachtung hier keine Rücksicht genommen habe.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Unsere D6-Exe ist 12-15 MB groß. Eine 50 MB Exe wäre nicht gerade von Vorteil (konnte bisher noch nicht das Hauptprogramm erfolgreich mit XE2 compilieren um den genauen Großenzuwachs mit und ohne Extended RTTI zu sehen

Und wenn es nun 50MB werden, wo lägen dann ganz konkret die Nachteile? Würden diese Nachteile den Verzicht auf ein so mächtiges Werkzeug wie RTTI wirklich rechtfertigen? Kannst du abschätzen, was dir das alles für Möglichkeiten eröffnet? Womöglich kannst du deinen Sourcecode damit ganz gehörig eindampfen.

Nur mal als Vergleich: bei einer meiner Anwendungen ist die Exe ausgehend von D7 bis nach XE2 (trotz RTTI und Unicode) gerade mal 25% größer geworden (9 -> 11,3 MB). Den erzeugten Mehrwert kann ich hier jetzt nicht beziffern, aber anhand der Kundenreaktionen würde ich ihn sicher über 25% ansiedeln. Als "Nebeneffekt" ist der Code auch wesentlich übersichtlicher und leichter wartbar geworden. Man muss nur mal den Mut haben, alte Zöpfe abzuschneiden.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1147128)

Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Wenn sich die Hersteller den Produktivitätsverlust leisten können und wollen ist ja alles ok. Schlecht ist nur, dass die dadurch entstehenden Entwicklungskosten sich nicht in den Versionen für die alten Delphiversionen wiederspiegeln, sondern meistens auf alle Käufer umgelegt werden...[/QUOTE]
Die meisten Komponentensammlungen werden wohl nicht mit 2010/XE(2) Neuentwicklungen sein sondern Weiterentwicklungen. D.h. man wird schrittweise neue Features einbauen und bei diesem Einbau sich überlegen ob man wegen dieser (erstmal verglichen mit dem Rest der Kompos) kleinen Features gleich D6-D2009 von den neuen Versionen abschneidet.

[Furtbichler]

Wobei man keins der "neuen" Features wirklich benötigt. Es erleichtert vielleicht etwas die Arbeit und in einer Softwareproduktion wird man effektiver arbeiten, aber ein Framework entwickeln geht auch mit den Sprachfeatures von Delphi 3. Wobei ich natürlich nicht von der IDE rede.