OOP in PureBasic die X.

[edel]

Vor allem da man bereits mit einigen Tricks und ein paar zusätzlichen Zeilen zumindest OOP-basiert programmieren kann. OOP typische Funktionen wie Polymorphie sind auch via kleinen Umwegen möglich.

Die (Moechtegern) OOP unter PB ist ein reiner Krampf. Die Zeit die man
bei mit der Implementation einer Klasse verplempert, machen die vielen
Funktionen von PB auch nicht wett. Dann lieber eine Sprache die OOP
unterstuetzt.

[inc.]

Hattest du eigentlich nochmal an deinem Parser gearbeitet?

[edel]

Ja, hatte dank Remi ja eine super Grundlage. Habe es dann aber
aus irgendeinem Grund abgeben, und da wird es wohl auch in
irgendeiner Schublade verschwunden sein.

[ZeHa]

Das ist eh so 'ne Sache... ich programmiere auch grundsätzlich objektorientiert, auch wenn die Sprache das nicht 100% bieten kann. Aber gerade unter PB kann man Strukturen voneinander ableiten und problemlos casten, also ist es so gesehen schonmal kein Problem. Man muß sich halt selbst ein wenig mehr um die Typsicherheit kümmern, aber für eigene Projekte dürfte auch das zu bewerkstelligen sein. Und so Dinge wie Konstruktoren und Destruktoren sind ebenfalls keine große Sache, also mir fällt jetzt nix direkt ein, was man damit wirklich nicht realisieren könnte.

[bembulak]

Die Zeit die man
bei mit der Implementation einer Klasse verplempert, machen die vielen
Funktionen von PB auch nicht wett. Dann lieber eine Sprache die OOP
unterstuetzt.

Zustimm!

[MASH]

Ich finde das ja eben in PB so passend das man PP programmieren kann aber über eigene Konstrukte (mittels DataSection, VT, Interface) doch an OOP heran kommt.

Daher ist es dann auch Sinnvoll COM,DCOM Module mittels dem quasi OOP zu coden wenn man hingegen nur eine DLL haben möchte schriebt man dies doch wieder in PP.

Ich bin dafür das PB auf PP ebene bleibt, eben möchte ich reines OOP dan nehme ich mir halt eine OOP Sprache, sollte PB dann OOP unterstützen hält mich nichts davon ab reines OOP dann auch in PB zu schreiben, allerdings kann ich mir dann vorstellen das PB dann wohl um längen langsamer wird. Oder halt der ein PreCompiler für OOP der dann Framework unabhängig läuft.

[Zaphod]

Ob OOP Sprachen langsamer sind hängt davon ab ob man OOP Sinnvoll oder unsinnig nutzt. Habe ich zwanzig Verebungsstufen oder erzeuge in einer schleife jedesmal ein temporäres Objekt, dass ich am ende der schleife bei jedem Durchlauf auch wieder zerstöre wird das Programm wohl langsamer laufen. Wenn ich OOP sinnvoll nutze, wird der unterschied kaum messbar sein. Ist mein Programm besser strukturiert, weil es leichter ist komplexe Zusammenhänge Objektorientiert zu formulieren als Prozedural, dann ist mein Programm möglicherweise am ende sogar schneller.

Das ist wie mit der Assembly Sprache.

[Hroudtwolf]

Oha. Mein Lieblingsthema zwingt mich hier auch mal wieder was zu schreiben. ^^

Das wird wohl eine ewige Diskussion in der PB-Community bleiben und weiterbringen wird sie uns auch nicht.
Leider lässt Fred hier einen ganz wichtigen Zug in Richtung professioneller Programmierung abfahren wenn er weiterhin darauf besteht aus idealistischen Gründen auf optionales, natives OOP in PB zu verzichten.

Der Ruf der Community wird schon seit Langem immer lauter nach einer nativen, anständigen OOP-Lösung in PureBasic.
Und so wie es ausschaut müssen erst Fremdentwickler einen Compiler entwickeln der das bietet.

Aber lassen wir mal die ungebackenen Brötchen im Ofen.

Viel interessanter sind die ewigen Pro&Contras zu nativer PB-OOP.
Während sich die einen nichts sehnlicher wünschen als eine simple optional anwendbare Erweiterung ihrer "Lieblingsprogrammiersprache" wehren sich andere mit Händen und Füssen gegen diesen Gedanken.
Letzteres kann ich allerdings nicht nachvollziehen.
Wo liegt in diesem strikten Ablehnen die Logik ?

Wenn euer Auto nen Turbo-Knopf hat den ihr nutzen "dürft", aber nicht müsst, würdet ihr es sicher nicht ablehnen zu fahren.

Wir reden hier schliesslich von einer simplen Erweiterung durch ein paar Keywords und wenige weitere Syntax-Faktoren die man einfach nutzen können soll wenn man möchte und sie nicht nutzen muss.

Auch Einsprüchen gegen die OOP wie in etwa "Man kann auch alles prozedural erreichen." kann ich nicht zustimmen.
Denn ich kann mir auch nen Tunnel durch den Berg graben um nach oben zu kommen anstatt dort bequem über nen Wanderweg hin zu kommen.

Die OOP eröffnet einem Programmierer nicht nur die Möglichkeit ein paar tolle Keywords zu benutzen.
Es erweitert seinen Geist.
Denn wer OOP programmiert, lernt anders zu denken.
Das mag nun sicher nicht jeder verstehen. Ist aber so.
Der Beweis liegt zum Beispiel in so tollen Konzepten wie MVC oder einfach ausgeklügelte objektorientierte Infrastrukturen welche sich weder prozedural lösen liesen oder ein PP-Only Progger jemals darauf kommen würde seine Projektproblematik auf solch einem Wege lösen.

Wenn ich nur an UML denke, welche ich als eine der grössten Inovationen in der modernen Programmierung und Projektplanung betrachte, könnte ich mir dafür beim besten Willen keine Anwendung für ein PP-Projekt aufgrund dort fehlender modularer Kapselungen und vorstellen.

Ich finde das ja eben in PB so passend das man PP programmieren kann aber über eigene Konstrukte (mittels DataSection, VT, Interface) doch an OOP heran kommt.

Alleine die Tatsache dass man sich über solche Verfahrensweisen die Übersicht im Quellcode versauen muss nur um objekt orientiert programmieren zu können, sollte doch für eine native, Keyword gestützte OOP in PureBasic sprechen.
Wobei man mit solchen Interface-Objects nichtmal tief hierarchische Composings programieren kann ohne sich nen Stack-Overflow zu holen.

Ich bin dafür das PB auf PP ebene bleibt, eben möchte ich reines OOP dan nehme ich mir halt eine OOP Sprache, sollte PB dann OOP unterstützen hält mich nichts davon ab reines OOP dann auch in PB zu schreiben, allerdings kann ich mir dann vorstellen das PB dann wohl um längen langsamer wird. Oder halt der ein PreCompiler für OOP der dann Framework unabhängig läuft.

OOP macht keine Sprache langsamer.
Der Programmierer tut dies höchstens durch falsche Konzipierung seiner Anwendung.
Es sind unwesentlich mehr pushs, pops und calls die bei der Ausführung von oo programmierten Anwendungen ihre Arbeit verrichten müssen.
Und solange die Verwendung von OOP optional bleibt gibt es auch keine dieser fast unmessbaren Geschwindigkeitseinbußen für den eingefleischten PP Progger.

Sein letztes Statement* dazu war ja recht klar formuliert, er will die BASIC-Programmierer nicht in zwei Lager spalten. Natürlich kann er seine Meinung dazu noch ändern, aber ich glaube, das wird er dann selbst ankündigen.
(*Freds)

Ich kann hier die Logik nicht ganz finden.
Es mag ja sein dass sich bei nativ, optionaler OOP sehr viele Progger finden werden die nur noch objekt orientiert programmieren und dementsprechend in der Com auch nur noch objektorientierte Sources puplishen würden.
Jedoch spaltet sich auch ohne die OOP Erweiterung bereits jetzt die Com in zwei Lager.
Nämlich die einen, die lieber moderne Programmiertechniken anwenden möchten und daher lieber auf ne andere Sprache satteln und die andern die halt auch so gern mit PB proggen und auch dabei bleiben.
Da sollte man sich doch mal fragen was wohl die bessere Alternative ist.





MfG

Wolf

[ZeHa]

Ein wichtiger Punkt vielleicht: Wenn OOP mit reingenommen wird, dann ist die bisherige, prozedurale API (die auf IDs basiert usw) irgendwie unpassend, und jeder Neuling, der PB aufgrund seiner wahnsinnig tollen OOP-Fähigkeiten kauft, wird sich fragen, warum die API nicht objektorientiert ist. Ich bin zwar auch für OOP, aber ich glaube, das ist dann schon etwas inkonsequent und ich kann zumindest verstehen, daß dies für Fred auch ein Problem wäre.

[AND51]

Objektorientiert zu programmieren finde ich ganz interessant.
Ich beherrsche selber JavaScript und Delphi (Delphi aus der Schule).

Dann bin ich auf PureBasic gestoßen und war sofort angenehm überrascht. Und zwar, weil es nicht objektorientiert ist. Denn IMHO ist z. B. in JavaScript die Syntax etwas umständlicher.
Was ich an PB so super finde, ist z. B. dass man keine Zeile mit einem Semikolon beenden muss. In PureBasic passieren mir auch weniger Schreibfehler, die ich dann beim Testlauf nicht erst raussuchen muss. Jeder kennt das, wenn man ungelogen 5 Minuten nach einem vergessenem Punkt suchen muss!

Zur Syntax: PB ist für mich so'n bisschen wie Asphalt, OOP wie Kopfsteinpflaa-a-a-a-aster. Ist zwar lustig, auf beidem zu fahren, aber ich persönlich finde PB angenehmer.

Beispiel JavaScript:

Code: Alles auswählen

var datum=new Date();
alert(datum.getDay());

window.focus();

window.document.write("Ein Beipieltext");

window.close();

PB:

Code: Alles auswählen

Define datum=Date()
MessageBox("", Str(datum))

SetActiveWindow(#fenster)

SetGadgetText(#Gadget, "Ein Beispieltext")

CloseWindow(#fenster)

@ Hroudtwolf / Turbo-Knopf
Du hast Recht. Ich fänd es nicht schlimm, wenn es OOP geben würde. Aber ich komme auch so zurecht, und das sogar gerne.
Außerdem zieht das Arguement mit dem Turbo-Knopf nicht, was meinst du, wie oft ich das schon bei den "Feature Requests" angebracht habe?

OOP mit reingenommen wird, dann ist die bisherige, prozedurale API (die auf IDs basiert usw) irgendwie unpassend

...was ich schon wieder blöd fänd. Wenn ihr euch mal überlegt, ihr schnappt euch nen Code aus der hiesigen Code-Tipps-&-Tricks-Ecke, was macht ihr denn, wenn ihr es prozedural gewohnt seid und der Code OOP ist? Dann musste dich ja erst durchwuschteln, bis du ihn verstehst. Wir sprächen dann zwar alle dieselbe Sprache (PureBasic), aber mit nem verschiedenem Dialekt. Ist doch genauso wie in Deutschland, jeder spricht Deutsch, nur die Bayern nicht (sagt man).