Was fehlt euch in Delphi?
Mir fehlen besonders die Templates, die man aus C++ kennt. Ich habe mal drei Klassen entwickelt, die fast gleich waren, da sie alle eine verkettete Liste darstellen, nur eben andere Datentypen. Hier würde ich mir wünschen, dass es eine Möglichkeit gibt, so etwas unabhängig vom Datentyp zu entwerfen zu können.

Des Weiteren würde ich es gut finden, wenn man in for-Schleifen angeben kann, wie sich die Laufvariable verändern soll (+2 ,* 3 usw.).

Mehr fällt mir atm nicht ein. ;)


Moderiert von Christian S.: Topic aus Sonstiges (Delphi) verschoben am Do 21.06.2007 um 00:08

Was ist das für eine Frage, wenn Du denkst C++ ist besser dann ist das so, über Geschmack lässt sich bekanntlich nicht streiten.

Wo hat er gesagt, dass er C++ besser findet?[1] Er findet nur, dass ein Feature von C++ sich auch ganz gut in Delphi machen würde.

Darüber nachzudenken, welche Funktionen in Delphi noch nett wären, ist doch völlig in Ordnung. Ich bin ein Fan von Chrome, weil die sich sehr viel Gedanken gemacht haben, was noch alles in eine Pascal-Sprache passen würde. Borland / CodeGear hat das sehr lange Zeit nicht getan und scheint auch jetzt eher langsam zu sein.


[1] Was man IMHO sowieso pauschal nicht sagen kann, höchstens "für Aufgabe X ist Sprache Y am Besten geeignet".

Christian S. hat folgendes geschrieben:

Wo hat er gesagt, dass er C++ besser findet?[1] Er findet nur, dass ein Feature von C++ sich auch ganz gut in Delphi machen würde. Darüber nachzudenken, welche Funktionen in Delphi noch nett wären, ist doch völlig in Ordnung. Ich bin ein Fan von Chrome, weil die sich sehr viel Gedanken gemacht haben, was noch alles in eine Pascal-Sprache passen würde. Borland / CodeGear hat das sehr lange Zeit nicht getan und scheint auch jetzt eher langsam zu sein. [1] Was man IMHO sowieso pauschal nicht sagen kann, höchstens "für Aufgabe X ist Sprache Y am Besten geeignet".

Genau das habe Ich damit gemeint.
Es kommen unsinnige Diskusionen über diese oder jene Sprache auf, was es ja hier schon zur geüge gab und wirklich keinen grossen Sinn ergibt.

Blackheart666 hat folgendes geschrieben:

Es kommen unsinnige Diskusionen über diese oder jene Sprache auf,

Dann beteilige Dich doch produktiv an der Diskussion.

*mit gutem Beispiel voran geh*
Ich hätte sehr gerne einen Two-Pass-Compiler in Delphi. Das würde einem Forwarding ersparen und auch das Problem der überkreuzenden Unit-Referenzen.

Schön fände ich, wenn Borland/CodeGear endlich mal ein Delphi für MacOS bringen würde und Kylix wieder aufnimmt.

Ohhhhh Jaaaaaaa, eine variable schrittgröße in For-Schleifen wäre fein.
Wenn ich mich nicht irre haben die aber schon ein paar Neuerungen hinzugefügt und es sollen weitere folgen.
Was ich aber noch genialer finden würde, wäre eine "Case" Selection bei der man auch String's angeben kann. Dieses ehwige If - Then Else ... ist manchmal ganz schön nervig. Und unübersichtlich.

Zitat:

Ohhhhh Jaaaaaaa, eine variable schrittgröße in For-Schleifen wäre fein.

Könnte man durch einen Präprozessor simulieren. Vielleicht baut es jbg ja in seine DLangExtensions ein, wenn du ihn darum bittest

Was mir ganz deutlich fehlt, sind dynamische Sprachfeatures. Damit meine ich, dass es möglich ist, einen Aufruf einObjekt.Methodenname oder einObject.PropertyName := ... zu machen, ohne dass bei der Kompilierung bekannt ist, ob das Objekt diese Methode oder Eigenschaft überhaupt kennt. Ich habe das bei Objective C und Ruby kennengelernt und möchte sowas nicht mehr missen - wer nur statisch gelinkte Sprachen wie Delphi oder C++ kennt, macht sich gar keinen Begriff davon, wie flexibel das ist. Das beste Beispiel, das ich kenne, ist Ruby On Rails. Ein so leistungsfähiges und gleichzeitig einfach zu verwendendes Framework kann man in Delphi meiner Meinung nach nicht bauen.

Das zweite was mir fehlt ist ganz klar ein Garbage Collector (für Win32 natürlich, mir ist klar, dass es das in .NET gibt).

Stefan

Zitat:

Was mir ganz deutlich fehlt, sind dynamische Sprachfeatures.

Geht doch in Delphi zum Teil auch (Com-Interfaces). Wiederspricht aber total dem Konzept der Typsicherheit.

mkinzler hat folgendes geschrieben:

Zitat: Was mir ganz deutlich fehlt, sind dynamische Sprachfeatures. Geht doch in Delphi zum Teil auch (Com-Interfaces). Wiederspricht aber total dem Konzept der Typsicherheit.

Okay, über COM-Schnittstellen geht es - aber ganz schön umständlich.

Was die Typsicherheit betrifft, bin ich der Meinung, dass ihr Vorteil deutlich überschätzt wird, wenn man objektorientiert entwickelt. In einer prozeduralen Sprache ohne strenge Typsicherheit wie zum Beispiel C stürzt das Programm wahrscheinlich ab oder es gibt schwer zu findende Fehler, wenn man Typen falsch verwendet, weil gar keine Typüberprüfung stattfindet. Eine moderne dynamische Sprache wie Ruby führt dagegen durchaus eine Typüberprüfung durch, sie findet nur zur Laufzeit statt.

Stefan

Zitat:

Eine moderne dynamische Sprache wie Ruby führt dagegen durchaus eine Typüberprüfung durch, sie findet nur zur Laufzeit statt.

Ruby ist genau wie PHP eine interpretierte Sprache, diese kann man imho nicht mit Sprachen wie Delphi, C#, Java usw. nicht vergleichen.

Templates vermisse ich nicht unbedingt Praktisch und eine wirklich sinnvolle Sache wären die Postfixoperatoren aus C: i++, i--, i&=4 etcpp. ein "Inc(i)" ist schon nicht schlecht, aber immer noch zuviel Tipparbeit Das ganze kann gern auf ordinale Typen beschränkt bleiben.

Ein weiteres Nice-to-have wäre das If(?-Konstrukt. Das "Iff" ist schon nicht schlecht, aber lückenhaft.

Zitat:

Praktisch und eine wirklich sinnvolle Sache wären die Postfixoperatoren aus C: i++, i--, i&=4 etcpp. ein "Inc(i)" ist schon nicht schlecht, aber immer noch zuviel Tipparbeit Das ganze kann gern auf ordinale Typen beschränkt bleiben.

Kann man auch anders drüber denken. Macht die Sache eher unübersichtlich. C ist nun mal C und Pascal Pascal

Zitat:

Ein weiteres Nice-to-have wäre das If(?-Konstrukt. Das "Iff" ist schon nicht schlecht, aber lückenhaft.

Was meinst du mit IIf()? Kenne das nur aus SQL

mkinzler hat folgendes geschrieben:

Ruby ist genau wie PHP eine interpretierte Sprache, diese kann man imho nicht mit Sprachen wie Delphi, C#, Java usw. nicht vergleichen.

Ob kompiliert oder interpretiert spielt doch keine Rolle - eine kompilierte Sprache kann die gleichen Features unterstützen wie eine interpretierte. Wenn dir Ruby als Beispiel nicht passt, nimm halt Objective C - das ist nicht ganz so elegant wie Ruby, weil es ein Aufsatz auf C ist, ist aber genauso dynamisch und ist eine normale Compilersprache.

Stefan

Also, ich muss sagen, allen Fürs und Widers zum Trotz:

Man hat in die IDE von Delphi 2006 schon eine Menge nette Dinge eingebaut, die meistens auch gut arbeiten, wie z.B. die Syntaxfehler-Hervorhebung während des Eintippens. Ich möchte es jetzt nicht mehr missen. Aber selbstverständlich vermisse ich auch einige Dinge in der Delphi-Sprache:

Das mit den Strings bei Case-Abfragen stimmt, das fehlt mir oftmals ganz außerordentlich, auch die Tatsache, dass bei den Case-Abfragen nur Konstanten erlaubt sind. Selbstverständlich ist das Case, so wie es jetzt existiert, leistungsfähiger als alle genannten Abarten/Zusätze, aber rein sprachlich würde man sich dann mit weniger Schreibarbeit auseinander setzen müssen.

Was mir persönlich am meisten fehlt, ist dieses nervige Fehlen einer direkten Update-Möglichkeit von DCUs ohne den Source, wenn ich von einem Delphi auf die nächste Version umsattele. Der in compilierten Units vorliegende Code ist doch so wie er ist, lauffähig, und solange er aufrufkompatibel mit den im Interface-Teil angegebenen Verweisen anderer Units ist, sollte das doch auch kein Problem sein.
Und ich finde es absolut nicht schön, dass bei einem Update die Komponentengalerien alle wieder neu compiliert/registriert werden müssen. Hier würde ich mir ein reibungsloseres Updaten wünschen. Ich habe mehrere Versionswechsel hinter mir und habe jedesmal tagelang nur damit verbracht, die Komponenten, die ich brauche, wieder herzustellen.

Aber ansonsten fehlt es mir eigentlich an nichts.

Zitat:

Das mit den Strings bei Case-Abfragen stimmt, das fehlt mir oftmals ganz außerordentlich, auch die Tatsache, dass bei den Case-Abfragen nur Konstanten erlaubt sind. Selbstverständlich ist das Case, so wie es jetzt existiert, leistungsfähiger als alle genannten Abarten/Zusätze, aber rein sprachlich würde man sich dann mit weniger Schreibarbeit auseinander setzen müssen.

Schau dir mal die DLangExtensions an

Hi,

was mich auch stört, auch wenn ich relativ selten an diese grenze Stoße ist die Begrenzung von Mengen auf 256 Elemente. Warum sollte es in heutzutage kein set of integer geben können?

Gruß
Klabautermann

Klabautermann hat folgendes geschrieben:

was mich auch stört, auch wenn ich relativ selten an diese grenze Stoße ist die Begrenzung von Mengen auf 256 Elemente. Warum sollte es in heutzutage kein set of integer geben können?

Na ja, da ist ja eine TBigSet-Klasse relativ schnell gebaut - wenn es nicht ohnehin schon irgendwo eine gibt. Würde mich wundern, wenn nicht...

Stefan