Fehlt Borland ein zweiter Anders Hejlsberg?? / Chrome

[Robert_G]

Zitat:

Zitat von malo

Zitat:

Zitat von LarsMiddendorf

Wenn man bei C# "{" "}" durch begin und end ersetzen und die Reihenfolge der Deklaration also Name:Type ändern und wieder procedure/function Syntax einfügen würde, dann wäre es das optimale Delphi .Net.

Also das find ich ja ÜBERHAUPT nicht. Ich mag die C/C++/C#-Syntax gar nich leiden.

Sind wir also wieder beim Syntaxgezicke angekommen? :roll:
@Lars
Nach einer Woche C# findest du begin & end nur noch hässlich, wobei ich es nach einer Stunde mit Delphi gar nicht mehr sooo schlimm finde. ;) Aber das ist nur meine Meinung. Schreibe dir doch einen AddIn für #develop oder das VS, der alle { als begin und alle } als end darstellt. :lol:

Zitat:

Zitat von malo

In Pascal / Delphi wird immer alles schön am Anfang deklariert, was auch vom Compiler so vorgeschrieben wird. In C# kann man Variablen-Deklarationen "irgendwo" einschieben, was das ganze mächtig unsauber macht, wie ich finde.

So ein Käse...
Wenn ich eine Variable innerhalb eines Scopes deklariere, existiert sie nur dort! Das heißt man muss nicht erst suchen wo & wie sie deklariert wurde.
Da sie nur dort existiert knalle ich mir meine Bezeichnerliste auch nicht sinnlos mit Variablen zu, die nur in der If-Clause 5 zilen drüber Sinn gemacht haben. ;)

Zitat:

Zitat von malo

Schlimm sind auch die leeren Parameter-Angaben in C#. Da muss man immer angeben, dass keine Parameter mitgeliefert werden, was Pascal-Compiler von alleine machen.

Auf dier Art kann man sofort sehen, das es sich um eine Methode handelt, auch wieder alles andere als unsauber. ;)

Zitat:

Zitat von malo

Dann die case-Abfragen. Echt schlimm, dass man jedes mal einzeln "case" schreiben muss.(gut, kein besonders gutes Argument, aber naja... :mrgreen: )

Falls du schonmal mit C# gearbeitet hättest, wüsstest du, dass man durch einen case durchfallen kann und im nächsten landet.
Auf die Art lassen sich eine Menge zusätzliche Verschachtelungen schon von Beginn an verhindern.

Zitat:

Zitat von malo

Und auch die Funktionen und Klassen werden "mittendrin" deklariert.

:lol: Der war gut.
Du scheinst einer dieser komischen "Ich-schreibe-alles-2-mal-weil-ich-es-sonst-nicht-lesen-kann" Vertreter zu sein.
Deshalb bräuchte ich dir eigentlich nicht sagen, dass Delphi Forward-Deklarationen benutzt weil der Compiler nicht in der Lage ist nach Defintionen zu suchen. Nicht, weil es _angeblich_ lesbarer sein soll.
Deshalb musst du alle Definitionen doppelt tippen (Wäre ja auch schlimm, wenn der arme Delphi-Compiler nicht nur stupide von oben nach unten rennen dürfte :roll: )

Zitat:

Zitat von malo

Deshalb kann ich gar nicht verstehen, was man so viel besser an C# als an Delphi finden sollte. Meine bescheidene Meinung: in C# wird mehr "hingeschmiert", während man in Delphi schön ein ordentliches Schema einhalten muss ;)

Der Style guide von C# ist wesentlich strenger als der von Delphi. Er umfasst schließlich nicht nur die Gr0ß/Kleinschreibung sondern auch in welcher Weise man Typen oder Instanzen benennt.
Als Folge davon hat man als style guide konformer Entwickler viele Vorzüge.
Die IDE schlägt dir Namen für Instanzen vor, sie kann autom. Properties & Constructors für Felder an legen, die code completion liefert auch erst solche Bezeichner, deren Name in der Situation am sinnvollsten sind ...

Aber nunja... Syntaxgezicke ist ziemlich synlos. Und dennoch habe ich mich darauf eingelassen. :wall:

[jbg]

Zitat:

Zitat von Robert_G

Du scheinst einer dieser komischen "Ich-schreibe-alles-2-mal-weil-ich-es-sonst-nicht-lesen-kann" Vertreter zu sein.

Und du wohl einer der "ich-ändere-dauernt-meine-Interfaces-um-meinem-Projektkollegen-eines-auszuwischen-und-müsste-deswegen-alles doppelt-schreiben" Vertreter.
Das Interface sollte eigentlich schon stehen, wenn man anfängt etwas zu implementieren. Und ein einfaches STRG+SHIFT+C reicht dann vollkommen aus, die Methodenrümpfe zu generieren. Ein Ändern des Interfaces sollte dann nicht mehr auftreten (ohne sich mit seinen Kollegen abzusprechen).

[delphifan2004]

Hallo S2B!

Du hast geschrieben:

Soweit ich das weiß, ist TWebBrowser eine ActiveX-Komponente und hat nichts mit den anderen Delphi-Komponenten zu tun.

Aber die Schnittstelle zu dieser Komponente hätte anders gekapselt werden können. Wie ich das Zeug anspreche ist doch der Komponente egal. Die von mir geforderten Methoden können doch die
korresponeierenden Methoden der ActiveX Komponente intern aufrufen. Ich rede ja nur von der Schnittstelle, welche die Komponente dann anspricht. Und die Schnittstelle kann durchaus standardisiert sein. Die Implmentation, die interne Repräsentation ist doch da Wurscht.

Mfg

Delphifan2004

[jbg]

Zitat:

Zitat von delphifan2004

Aber die Schnittstelle zu dieser Komponente hätte anders gekapselt werden können.

Und Borland soll jetzt alle ActiveX Komponenten die es gibt, per Hand kapseln? Die WebBrowser Kapselung ist nichts anderes als automatisch erzeugter Code. Borland war nur so nett, und hat die WebBrowser ActiveX-Komponente ab der Prof Version schon vorgeneriert.

[malo]

Zitat:

Zitat von Robert_G

Sind wir also wieder beim Syntaxgezicke angekommen? :roll:

Genau ;)

Zitat:

Zitat von Robert_G

So ein Käse...
Wenn ich eine Variable innerhalb eines Scopes deklariere, existiert sie nur dort! Das heißt man muss nicht erst suchen wo & wie sie deklariert wurde.
Da sie nur dort existiert knalle ich mir meine Bezeichnerliste auch nicht sinnlos mit Variablen zu, die nur in der If-Clause 5 zilen drüber Sinn gemacht haben. ;)

Ich mein damit eher lange Funktionen. In C# kann man die nötigen Variablen der jeweiligen Funktion "irgendwohin" schreiben, während Pascal ein ordentliches Schema vorgibt. D.h. du musst am Anfang in einem eigenen Variablen-abschnitt die jeweiligen Variablen deklarieren und kann sie nicht "so lala" irgendwo deklarieren, wie in C#.

Zitat:

Zitat von Robert_G

Auf dier Art kann man sofort sehen, das es sich um eine Methode handelt, auch wieder alles andere als unsauber. ;)

Aber man muss ja vorher wissen, ob es eine Methode ist, damit man weiß, ob man (leere) Parameter übergeben muss, oder nicht. Deshalb: Einfach nur nervig ;)

Zitat:

Zitat von Robert_G

:lol: Der war gut.
Du scheinst einer dieser komischen "Ich-schreibe-alles-2-mal-weil-ich-es-sonst-nicht-lesen-kann" Vertreter zu sein.
Deshalb bräuchte ich dir eigentlich nicht sagen, dass Delphi Forward-Deklarationen benutzt weil der Compiler nicht in der Lage ist nach Defintionen zu suchen. Nicht, weil es _angeblich_ lesbarer sein soll.
Deshalb musst du alle Definitionen doppelt tippen (Wäre ja auch schlimm, wenn der arme Delphi-Compiler nicht nur stupide von oben nach unten rennen dürfte :roll: )

ICH persöhnlich finde die Pascal-Version bedeutend übersichtlicher. Da hat man gleich zu Anfang einen Überblick, welche Funktionen und Procedures es gibt. Und man kann sich auch drauf einstellen, während man bei C# wie ein verrückter suchen muss.

Zitat:

Zitat von Robert_G

Der Style guide von C# ist wesentlich strenger als der von Delphi. Er umfasst schließlich nicht nur die Gr0ß/Kleinschreibung sondern auch in welcher Weise man Typen oder Instanzen benennt.
Als Folge davon hat man als style guide konformer Entwickler viele Vorzüge.
Die IDE schlägt dir Namen für Instanzen vor, sie kann autom. Properties & Constructors für Felder an legen, die code completion liefert auch erst solche Bezeichner, deren Name in der Situation am sinnvollsten sind ...

Mir geht es nicht um einen "strengen Style Guide", sondern um Übersichtlichkeit. Pascal sorgt für Übersichtlichkeit, indem es vorgibt, wo Variablen zu deklarieren sind und gibt auch die Forward-Deklarationen vor, wo man Funktionen und Klassen schon vorher ankündigen muss. So kann man auch Funktionen und Klassen finden, bevor man den ganzen Quelltext durchsucht. In C# ist es ja leider so, dass man, wenn man Pech hat, ohne Ende nach Variablen-Deklarationen suchen muss.

[SirThornberry]

@malo: ich will dich nicht enttäuschen, aber unter delphi muss man nicht umbedingt forwarddeklarartionen verwenden (zumindest bei einfachen procedure und funktionen (die keine methode eines objectes sind)

[Robert_G]

Zitat:

Zitat von jbg

Zitat:

Zitat von Robert_G

Du scheinst einer dieser komischen "Ich-schreibe-alles-2-mal-weil-ich-es-sonst-nicht-lesen-kann" Vertreter zu sein.

Und du wohl einer der "ich-ändere-dauernt-meine-Interfaces-um-meinem-Projektkollegen-eines-auszuwischen-und-müsste-deswegen-alles doppelt-schreiben" Vertreter.
Das Interface sollte eigentlich schon stehen, wenn man anfängt etwas zu implementieren. Und ein einfaches STRG+SHIFT+C reicht dann vollkommen aus, die Methodenrümpfe zu generieren. Ein Ändern des Interfaces sollte dann nicht mehr auftreten (ohne sich mit seinen Kollegen abzusprechen).

Stimmt, den konnte man falsch verstehen. ;)
Unter Delphi32 hat das durchaus Sinn gemacht. Da habe ich anfangs auch erst leere Rümpfe erstellt und per Class completion kompilierfähig gemacht.
Wobei ich schon kurze Zeit später in den Packages meine Freunde gefunden habe. D.h.: Ein Entwickler schreibt ein Package, alle anderen verwenden nur die kompilerte Form. Falls sich größe Änderungen in der Struktur zeigen müssen zwar die anderen Entwickler ein paar Änderungen in ihren Packages machen, aber das sollte nicht sehr häufig vorkommen. ;)
Da jeder für sein Package zuständig ist, müssen sich die anderen auch nicht mit dem Code eines fremden Packages ärgern.
Unter .Net wurden Packages durch ClassLibraries ersetzt und es funktioniert auch dort prima.
Wenn alles läuft wie es soll kann man mehrere Packages zu einem zusammenführen ohne dass Änderungen im Code nötig wären.

Man kann 1.000 Argumente suchen warum Forward Deklarationen sinnvoll sein sollen, es finden sich aber bestimmt 1.001 Argumente warum sie nur nervig, hässlich und Artefakte aus der dunklen Turbo Pascal Ära sind.

Und an der Stelle beende ich die Diskussion, da Syntaxgezicke nunmal absolut nix bringt. (Die Einsicht hätte ich gestern abend schon haben sollen :oops: )

@Malo
Ich lasse deinen Post mal weitestgehend unkommentiert. Er zeigt eindeutig, dass du entweder nie mit C# gearbeitet oder nur den C#-Builder von Borland genommen hast. :mrgreen:
Schon mit #develop oder dem VS gibt es die Probleme nicht, da man einfach genügend Infos aus Syntaxhighlighting, Code Completion und dem Class browser erhält. ;)

@SirT
Man muss, außer man kann es verantworten seinen Code auf die Art zu verschandeln. (Bisher hat sich immer gezeigt, dass OOP-FOP Mischmasch nie sehr leserlich & wartbar war ;) )

[malo]

Zitat:

Zitat von SirThornberry

@malo: ich will dich nicht enttäuschen, aber unter delphi muss man nicht umbedingt forwarddeklarartionen verwenden (zumindest bei einfachen procedure und funktionen (die keine methode eines objectes sind)

Stimmt, trotzdem halte ich es für übersichtlicher, es so zu machen. Und ich persöhnlich deklarier die Funktionen und Procedures meist auch als Methoden einer Klasse, eben wegen der Übersicht ;)

[SirThornberry]

@Robert_G: hab ich gesagt das ich so arbeite? Sowas mach ich maximal in einer DLL oder für meine tools-unit. Zum beispiel für eine Funktion die mir die macaddressen zurückgibt finde ich es overkill extra eine klasse anzulegen zumal getcursorpos etc. ja auch keine klassen sind. Wird also nur für globale funktionen genutzt die man auch in anderen projecten braucht und dort benötige ich dann auch die forwardeclaration dammit im declarationsabschnitt nur die header sind und somit die funktionen außerhalb der unit auch erreichbar...

Hab auch nix gegen das C# - also jetzt ni auf mich los gehen :-D