Stärken und Schwächen von Object Pascal

[monta]

ich denk mal, er musste ja auch seine 'eigene' Sprache verteidigen. (und ich denk mal, er meinte Python )

Ist ja auch klar, das hier keiner schreibt, Object-Pascal ist Sch..., weil, warum wäre er dann hier?

Aber von der Syntax her ist Pascal eine sehr klare Sprache.

[John]

Mann muss auch noch dazu sagen das einer der Vorteile ist, ist das es einfach zu erlernen ist und deshalb auch für Anfänger gut geeignet ist. Zwar ist bandbreite sehr Groß für das was man es benutzen kann, aber einfache sache kann man auch sehr einfach machen.


John

[pluto]

ich sehe das genauso ! wobei ich davon ausgehe das er keine Lieblings Sprache hat.
Das er einfach die Sprache nutzt die für das Problem am besten Geignet ist.

Nicht das ihr jetzt das Gefühl bekommt, das ich Pascal nicht mehr mark. ganz im gegenteil: Ich finde Pascal oder auch Object Pascal einfach toll..

Gerade weil sie so einfach ist in fielen bereichen. z.b. habe ich gesehen das es in Python keine case Anweisung gibt. Ich nutze es in Pascal jetzt immer mehr.... weil ich gesehen habe das damit eine menge code gespart werden kann.

Und es gibt dort auch nur 2 schleifen(for und while) nagut, eigentlich ausreichend.
aber die Repeat schleife finde ich auch nicht unbedingt verkehrt.

[mschnell]

Mit Pointern, vor allem untypisierten, kann man natürlich beliebiges Chaos anstellen und alles kaputt machen. Wenn man nicht genau weiß, was man tut, kann man sie aber auch einfach nicht benutzen.

ich kenne bisher nur zwei schwächen, die mir aber nix ausmachen:
- Zikluärer Aufruf von unit
- Keine Mehrfach Vererbung.

Ob der Mangel an Mehrfach-Vererbung eine Schwäche ist, kann man kontrovers diskutieren. Hiermit kann man zwar nette Sachen machen, aber auch ungewollt erhebliches Chaos veranstalten. Bei Objekt-Pascal kann man mit Interface so etwas ähnliches aber in gezähmter Art machen.

Als Stärken finde ich die Property Eigenschaft praktisch.

Ohne Property ist für mich keine echte Objekt-Orientierung.

Und im laufe des Gesrpäch sagte er noch, ja OOP kam ja dazu es wahr ja nicht geplant gewesen.... und das Konzept würde in "Object Pascal" auch kein echtes OOP sein.

Genau wie C -> C++ bzw C -> Java oder C -> C# .
C# ist zudem heftig bei Object Pascal abgeguckt.

-Michael

[mschnell]

das wenn du auf ein objekt zugreifst das nicht existiert du eine access violation bekommst du das also auch nicht machen kannst.

Wenn man auf ein Objekt zugreift, das nicht existiert, bekommt man nicht mit Sicherheit eine access violation. Es kann auch beliebiges Chaoas passieren:

Code: Alles auswählen

a := TStringList.create;
  a.free;
  a.add('test');

-Michael

[mschnell]

in Phytong ist das nicht so, wie ich es unter Wiki nach gelesen habe. Dort wirst du gezwungen eine gewisse Sorgfalt zu benutzen.

Da kann man sich auch d'rüber streiten. In Python verwendet man untypisierte Variablen. Das finde ich alles andere als "gezwungen eine gewisse Sorgfalt zu benutzen".

-Michael

[mschnell]

Mann muss auch noch dazu sagen das einer der Vorteile ist, ist das es einfach zu erlernen ist und deshalb auch für Anfänger gut geeignet ist.

Heute wird gerad Python für Anfänger empfohlen. Finde ich nicht so gut, vor allem da dort keine strenge Typisierung verwendet wird, und gerade das m.E. eine Erziehung zu einem sauberen Programmier-Stil darstellt.

Die (ursprünglich Borland-) Object-Pascal-Sprache hat den Vorteil, dass man damit alles machen kann, was auch in C (und Assembler) möglich ist (u.U. nicht ganz so effektiv) und - wenn man solche Spezialitäten nicht verwendet - trotzdem sehr lesbaren Code erzwingt und deshalb immer noch zur Ausbildung gut geeignet ist.

-Michael

[Christian]

Ach nochwas der Zirkuläre Unit aufruf ist keine Schwäche von Objekt Pascal das geht nirgends. Macht auch keinen Sinn.

[pluto]

Im Grunde hast du recht, aber es währe halt schön, wenn das gehen würde. Schwer ist das mit Sicherheit nicht einzubauen, dann hätte man halt noch mehr Freiheiten. Weil wenn man eine Klassen Sammlung erstellt muss man das Berücksichtigen.

Und mehrere Große Klassen in einer Unit zu haben, ist nicht besonders schön. Ich komme schon mit zwei Klassen in einer Unit durcheinander und bin zwischendurch in der Falschen Klasse.

Aber gut, dann muss man damit halt leben das es so ist. Er meinte dieses "Problem" währe z.b. in Python nicht der Fall. Aber ich denke ich werde nicht versuchen Python zu lernen weil es einfach für mich kein Sinn ergibt auch wenn es eine "schöne" sprachen ist.

Da sollte ich ehere versuchen C++ bzw. CShap(oder .net) zu lernen das würde mehr sinn ergeben, weil danach wird ja im Moment sehr viel gesucht besonders .net,

Ich würde halt schon gerne wie gesagt eine zweite Sprache können.

Java gefällt mir nicht
Perl ist mir zu Unleserlichkeit
Php habe ich noch nicht viel gemacht, aber ich glaube hier triff das gleiche zu wie in Perl
Unix Shell das gleiche wie in Perl wobei ich schon mehr gemacht habe

VBS kommt von MS; daher wollte ich es nicht nutzen.
Ada habe ich noch nix mit gemacht, aber von der Syntax geflät es mir gut
TCL_TK naja ich weiß nicht so recht.

[Christian]

Pluto, das geht nicht !
Da beist sich die Katze in Schwanz es ist einfach nicht realiserbar. Klopf bitte nicht immer solche Sprüche wie

Schwer ist das mit Sicherheit nicht einzubauen

Wenn dem so ist, dann tu es bitte.
Ist aber Quatsch das Unit Konzept ist etwas streng mit den header Files über den Präprozessor ist das in C/C++ und glaub auch in Python etwas loser dort stolperst du aber noch viel schneller über probleme wenn man z.b. mal vergisst ein Headerfile in defines zu fassen dann hat man ganz schnell mal nen Linker Fehler weil die Variable 3x deklariert ist und sucht sich nen Wolf.

Man muss auch nicht immer alle Units in der interface Section in die uses schreiben die meissten sollten eigentlich eh in die implementation uses und wenn du das beherzigst wirst du nie wieder Probleme mit zirkulären Referenzen haben.

[pluto]

Das sagst du so einfach. Ich habe z.b. jetzt drei units eine Bases Klasse ist in unit1 drin in unit2 ist jetzt eine Klasse von der Bases Klasse abgeleitet. Aber diese Klasse braucht eine klasse aus unit3 und unit3 braucht wieder rum eine klasse von unit1.... schon ist das Problem da.

[monta]

Also ich hatte irgendwie noch nie Probleme mit der Unitreferenz. Nur das erste mal, wo ich noch keinen plan von Delphi hatte und irgendwie die Unit da hinzufügen wollte...aber wenn man es weiß, ists doch kein Problem mehr. Und wozu willst du das eigentlich Pluto, du siehst doch, das auch alles ohne geht.

Und wenns wirklich nicht geht, dann müssen halt zwei Klassen in eine Unit.

[mschnell]

Das sagst du so einfach. Ich habe z.b. jetzt drei units eine Bases Klasse ist in unit1 drin in unit2 ist jetzt eine Klasse von der Bases Klasse abgeleitet. Aber diese Klasse braucht eine klasse aus unit3 und unit3 braucht wieder rum eine klasse von unit1.... schon ist das Problem da.

Wie meinst du "braucht" ?

Wenn einer Variable dieser Klasse deklariert wird geht das, glaube ich, so:

Code: Alles auswählen

TX = class; 
 
TY = class
public
  X: TX;
end;
 
TX = class
public
  Y: TY;
end;

Müsste doch eigentlich auch gehen, wenn die Deklarationen in verschiedenen Units sind.

-Michael

[pluto]

nur schade das keine Forwad defniationen unit übergreifend sind.

[Christian]

Das sagst du so einfach. Ich habe z.b. jetzt drei units eine Bases Klasse ist in unit1 drin in unit2 ist jetzt eine Klasse von der Bases Klasse abgeleitet. Aber diese Klasse braucht eine klasse aus unit3 und unit3 braucht wieder rum eine klasse von unit1.... schon ist das Problem da.

Nö, da ist gar kein problem die einzige Unit wo in die interface section ein uses rein muss ist unit2, unit 1,3 können jewails die uses für die anderen units in der implementation stehen haben und es gibt nie ne cirkulare referenz.

nur schade das keine Forwad defniationen unit übergreifend sind.

Quark, jede deklaration im interface teil ist übergreifend. Du solltest mal Pascal lernen und nicht nur code kopieren.