PureBasic, C++, Java und die ganze Sprachenscha(r)

[Kaeru Gaman]

ja und nein.

man muss schon einiges drumrum stricken, um klassen aufzubauen, aber es geht grundsätzlich.

http://www.purebasic-lounge.de/viewforum.php?f=96

[Tafkadasom2k5]

Das ist mir ein wenig zu schwere Kost gerade, als das ich es verstehen könnte...

Aber scheint ja irgendwie zu gehen (auch wenn die Syntax mir dadurch ein wenig spartanisch vorkommt- bin was OOP angeht eben von Java verwöhnt... ).

Gr33tz
Tafkadasom2k5

[Zaphod]

Prinzipielll wäre es möglich eine Objektorientierte Sprache mit einem präprozessor zu erzeugen, die C++ in nichts nachsteht... die ersten C++ Kompiler waren auch nur präprozessoren für C.

Damit handelt man sich aber sehr viel ärger ein, denn dann hebelt man eventuell viel fehlererkennung des eigentlichen Kompilers aus.

Man kann aber schon viel "objektorientiertheit" durch hacks und geeignete frameworks erhalten, ob dass eine Sprache dann zu einer objektorientierten macht, darüber kann man vortrefflich streiten.

Für C gibt es auch "objektorientiertheit auf bibliotheksebene" zum Beispiel in Form der glib... ich vertrete aber nicht die meinung, dass C deswegen eine objektorientierte Sprache ist.

[inc.]

Richtige OOP kommt ja erst via Vererbung und Polymorphie zum Zuge (meine ich mal irgendwo gelesen zu haben).

Im Link kann man lesen, was den Ansatz der Polymorphie in PB-OOP ausmacht und wie man es angehen 'kann'. Zudem ist im Beispiel auch Vererbung integriert.
http://www.purebasic-lounge.de/viewtopic.php?t=3463

Wenn man es genau betrachtet ist es eigentlich recht übersichtlich. Da aber in PB die Vererbung und eine erneute MethodenZeigerzuordnung manuell erledigt werden muss, ist der 'nicht native' OOP Ansatz in PB noch weit vom C++/Java Klassen-Komfort entfernt.

Prinzipielll wäre es möglich eine Objektorientierte Sprache mit einem präprozessor zu erzeugen, die C++ in nichts nachsteht.

Da wäre noch Überladung fällig Und das würde eine Variablenerkennung und sodann Zuordnung individueller Prozeduren im Preprozessor erforderlich machen = Fummmmmmelei

[Ligatur]

Bei C++ gibt es dafür scope Modifyer. Es gibt Private, Öffentliche und inerhalb einer vererbung sichtbare eigenschaften und methoden... eine objektorientierte sprache die ausschließlich private eigenschaften und methoden hat währe so sinnvoll wie write-only speicher.

Es spricht auch nichts dagegen, dass man unkritische eigenschaften direkt zugänglich macht. Wenn das gegen die Objektorientiertheit verstieße, dann gäbe es keine objektorientierten Sprachen. Wenn ich mich richtig erinnere gibt es die sogar bei smalltalk, der Mutter aller objektorientierten Sprachen.

Objektorientiertheit ist auch nicht das gleiche wie datenkapselung, auch wenn viele schlechtere Bücher das immer wieder behaputen. Es muß nur die Möglichkeit zur kapselung geben, nicht den Zwang.

Von Methoden habe ich gar nicht gesprochen, diese müssen selbstverständlich global zugänglich sein können, anders aber die Eigenschaften, also die Klassenvariablen. Diese dürfen nur über Get-/Set - Funktionen angesprochen werden, falls die Sprache wirklich objektorientiert sein soll. So habe ich das jedenfalls mal gelernt.

[Kaeru Gaman]

das nennt man kapselung, und ist auch kein problem.

natürlich könnte man gekapselte auch manipulieren, das kann man immer.

[Zaphod]

@Ligatur:

Die *möglichkeit* zur Kapselung muß da sein, aber nicht der *zwang*. Kapselung von daten ist überall da sinnvoll, wo Konflikte durch unqualifiziertes herumfummeln an internen zuständen entstehen können.

Es ist aber nicht sehr zweckmäßig, wenn eine Programmiersprach dich auch da zu einem Getter/Setter zwingt, wo die zuordnung nur durch eine einzelne zuweisung/einem einzelnen return erfolgt.

Darum macht das auch keine objektorientierte sprache, weil der prinziepielle zwang vollkommener quatsch wäre.

[Ligatur]

@Ligatur:

Die *möglichkeit* zur Kapselung muß da sein, aber nicht der *zwang*. Kapselung von daten ist überall da sinnvoll, wo Konflikte durch unqualifiziertes herumfummeln an internen zuständen entstehen können.

Es ist aber nicht sehr zweckmäßig, wenn eine Programmiersprach dich auch da zu einem Getter/Setter zwingt, wo die zuordnung nur durch eine einzelne zuweisung/einem einzelnen return erfolgt.

Darum macht das auch keine objektorientierte sprache, weil der prinziepielle zwang vollkommener quatsch wäre.

Da hole ich mir doch gleich mal Alan Kay zu Hilfe, der den Begriff der Objektorientiertheit prägte:

.

Bei der objektorientierten Programmierung beschreiben Programme, wie Nachrichten zwischen Objekten ausgetauscht werden. Ein Objekt ist ein Baustein, der Zustände und Prozesse enthält, die er schützt und versteckt und auf den von außen nur durch Austausch von Nachrichten zugegriffen werden kann. Dabei entscheidet ein Objekt selber, wie es auf eine bestimmte Nachricht reagiert. Es muß möglich sein, daß erst äußerst spät (während des Programmablaufs) festgelegt wird, welches Objekt eine bestimmte Nachricht erhält (späte Bindung). (frei nach [0] und [1])

Objektorientierte Programmierung im ursprünglichen Sinne ist nach Kay ist zur Zeit (2003) nur in der Programmiersprache Smalltalk und in der Programmiersprache Common Lisp möglich. Andere, oft als „objektorientiert“ bezeichnete Programmiersprachen, wie die Programmiersprache Java oder die Programmiersprache C++, sind keine objektorientierten Programmiersprachen im Sinne Alan Kay s.

Siehe http://userpage.fu-berlin.de/~ram/pub/p ... mierung_de

[Kaeru Gaman]

wozu nen priester zitieren, wenn man selber mit göttern reden kann?

das der zwang zur kapselung nicht sinnvoll ist, ist ein völlig logisches argument.

außerdem: da steht, C++ und JAVA sind keine OOP nach Kay.

[ts-soft]

UserLib erstellen, dann ist alles gekapselt und man kommt nur noch über das
Object-Interface daran. (Es sei denn, man benutzt ASM um die nicht
exportieren Funktionen zu nutzen )