Warum ist Delphi/(Pascal) bei uns so beliebt? (und wie erklären wir das den Neuen?)

[EWeiss]

Hmm denke du hast mich nicht verstanden..
Ich habe nicht von Klassen geredet.

Bsp:

Delphi-Quellcode:

procedure Mein(bla, bla);
begin

  Recursive(geht nix);
end;

procedure Recursive(blaaa);
begin

end

Wie du siehst steht Recursive unter Mein.
Und das wird nicht gefunden wenn ich Recursive(geht nix); aufrufe.
In dem Fall muss ich Recursive(blaaa); Global definieren oder in eine Klasse unterbringen andernfalls wird es nicht gefunden.
Zumindest nicht unter D2010.

Als Einsteiger bzw.. als jemand der von VB6 nach Delphi gewechselt ist war es nicht so einfach das zu verstehen.
Da unter VB6 es egal war wo eine Procedure oder function abgelegt wurde.
Bei einer Alphabetischen Reihenfolge (Formatierung des Quelltextes) würde bei Delphi dann nichts mehr gehen.

Zitat:

Ich hätte lieber das man proceduren und functionen auch recursive in den Units finden könnte.

Ich habe von einer Unit geredet nicht von kreuzverlinken (UNIT'S)
Siehe mein Beispiel!

gruss

[Mavarik]

Zitat von EWeiss:

Hmm denke du hast mich nicht verstanden..

Du hast es nicht verstanden... in diesen Fall musst du nur die forward declaration benutzen...

Nix global, nix in einer Klasse. Und schon kann deine Procedure drunter stehen.

[EWeiss]

Zitat von Mavarik:

Zitat von EWeiss:

Hmm denke du hast mich nicht verstanden..

Du hast es nicht verstanden... in diesen Fall musst du nur die forward declaration benutzen...

Nix global, nix in einer Klasse. Und schon kann deine Procedure drunter stehen.

forward; // explizit Ach so.. Hmm ehrlich das wusste ich nicht.
Sehe ich aber als Unsinnig an dafür extra ein direktive für anzulegen.
Aber gut wenn's geht.

Nebenbei eine Garantie ist es auch nicht wenn ich meinen Quelltext anschließend Alphabetisch sortieren würde.
Dann nutzt auch ein Forward nichts.

gruss

[dGeek]

Zitat von EWeiss:

forward; // explizit Ach so.. Hmm ehrlich das wusste ich nicht.
Sehe ich aber als Unsinnig an dafür extra ein direktive für anzulegen.

Da stimme ich zu. Bei einem so teuren Produkt sollte man eigentlich davon ausgehen können, dass das auch ohne extra-Definition möglich ist.

[Mavarik]

Zitat von dGeek:

Da stimme ich zu. Bei einem so teuren Produkt sollte man eigentlich davon ausgehen können, dass das auch ohne extra-Definition möglich ist.

OMG: Was hat das den damit zu tun?

Es geht hier um die Syntax von Pascal...
Und da ist die Regel ganz einfach: Es wird NIX verwendet, was nicht vorher definiert ist.

Abgesehen davon kann das der 1-Pass-Compiler sowieso nicht...

[jaenicke]

Zitat von EWeiss:

In dem Fall muss ich Recursive(blaaa); Global definieren oder in eine Klasse unterbringen andernfalls wird es nicht gefunden.

Das ist eine der guten Seiten von C#. Da kann man nicht einfach irgendwelche Methoden lose irgendwo hinwerfen. Da ist man gezwungen diese in namespaces, Klassen usw. einzusortieren.

Leider ist dies eine der Altlasten des rein prozedural orientierten ursprünglichen Pascal, dass das in Delphi heute noch geht. Ansonsten wären viele Quelltexte viel besser strukturiert.

[uligerhardt]

Zitat von jaenicke:

Das ist eine der guten Seiten von C#. Da kann man nicht einfach irgendwelche Methoden lose irgendwo hinwerfen. Da ist man gezwungen diese in namespaces, Klassen usw. einzusortieren.

In Namespaces? Muss schon ne Klasse sein, oder?
Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

[jaenicke]

Zitat von uligerhardt:

Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

TMath.Sin usw. als Klassenmethoden macht schon Sinn, weil man dann das ganze so thematisch unterteilt und nicht mehr einfache Prozeduren herumfliegen hat.

Denn ansonsten fehlt dir z.B. die Syntaxergänzung oder du schreibst den ganzen Unitnamen ab.
So schreibst du einfach TMath. und siehst die verfügbaren Methoden ohne tausend weitere globale Prozeduren zu sehen.

[uligerhardt]

Zitat von jaenicke:

Zitat von uligerhardt:

Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

TMath.Sin usw. als Klassenmethoden macht schon Sinn, weil man dann das ganze so thematisch unterteilt und nicht mehr einfache Prozeduren herumfliegen hat.

Denn ansonsten fehlt dir z.B. die Syntaxergänzung oder du schreibst den ganzen Unitnamen ab.
So schreibst du einfach TMath. und siehst die verfügbaren Methoden ohne tausend weitere globale Prozeduren zu sehen.

Da macht das Formelschreiben Spaß. Und Sin krieg ich ohne Syntaxvervollständigung hin.

[OlafSt]

Das mag bei simplen bzw. oft genutzten Dingen wie mathematische Funktionen noch unsinnig erscheinen.

Doch wie ist das z.B. mit TFormatSettings ? Da kenne ich bei weitem nicht alle Elemente, die sich dahinter verbergen. Ähnlich ist es in .NET mit der statischen Math-Klasse, der Converter-Klasse (die nahezu alles in alles Konvertieren kann und weit über IntToStr oder TStringList.DelimitedText='bla' hinausgeht), der BitConverter-Klasse und so weiter.

Gerade am Anfang, wenn man noch neu in .NET ist, ist das eine unschätzbare Hilfestellung. Ein Delphi-Neuling muß lernen, das man einen Int per "IntToStr" in einen String verwandelt. Und das es noch FloatToStr und FormatDateTime usw. usf. gibt... Dem .NET-Neuling sagt man "schau in die Convert-Klasse" und er findet von selbst den Weg zu all diesen Konvertierungen.

So unsinnig ist das ganze also nicht