Vorstellung der Sprache C-mol - methodenorientierte Softwareentwicklung

SendKey

@Bitsy:
Das bringts ganz gut auf den Punkt.
Das denken in "Verben" ist ja eigentlich der Ansatz, der MOP zugrunde liegt!

@Helium:

Helium schrieb:

Mit Aufleitungen muss ich erstmal etwas rumexperimentieren. Villeicht ist es ja wirklich sinnvoll.

Wenn ich das richtig verstanden habe kann man so auf bequeme Art und weise Multidispatcher schreiben:
method Differenzflaeche () {
   virtual int <Rechteck, Rechteck> ()
   { ... }
   virtual int <Rechteck, Kreis> ()
   { ... }
   virtual int <Kreis, Kreis> ()
   { ... }
   ...
};

Hier benutzt Du ja bislang keine Aufleitung! Hier hast Du drei Multihandlings, die aber teilweise für identische Typen definiert sind. Hier würde der Compiler schon beim ersten Handling sagen, das ein identisches Handling für Rechteck mehrfach definiert ist.

Hier ein Beispiel für Aufleitung von Methoden. Es geht dabei um die Animation grafischer Objekte (als Konsole-Applikation). Aufleiten bedeutet u.a. Redundanzen in Prologen und Epilogen verschiedener Methoden auf einer höheren Abstraktionebene in einer Art "Meta-Prolog/-Epilog" zusammenzufassen:
C-mol Code:

#include <stdio.h>
#pragma c-mol_hdrstop

class CTisch
	{
	};

class CTuer
	{
	};

// Eine Integrationsmethode
method MDrehe(int Grad)
	{

	MDrehe()
		{
		printf("Drehen beginnt...\n");
		}

	~MDrehe()
		{
		printf("Drehen endet.\n\n");
		}

	void <CTisch>()
		{
			printf("Tisch wurde um %d Grad gedreht!\n", Grad);
		}
	};

// Eine Integrationsmethode
method MOeffne()
	{

	MOeffne()
		{
		printf("Oeffnen beginnt...\n");
		}

	~MOeffne()
		{
		printf("Oeffnen endet.\n\n");
		}

	void <CTuer>()
		{
			printf("Tuer wurde geoeffnet!\n");
		}
	};

// Die Integralmethode
method MAnimiere(int x, int y) : MDrehe, MOeffne
	{

	// "Meta-Prolog" für alle geerbten Handlings
	MAnimiere()
		{
		printf("Bewegung zu Koordinaten: x=%d, y=%d\n\n", x, y);
		}

	// "Meta-Epilog" für alle geerbten Handlings
	~MAnimiere()
		{
		printf("Bewegung vollstaendig abgeschlossen!\n\n");
		}
	};

// HAUPTPROGRAMM
int main()
	{
	CTisch Tisch;
	CTuer Tuer;

	MAnimiere(50,20)°Tisch(30);
	MAnimiere(30,80)°Tuer();

	return 0;
	}

In der C-mol-Download-Sektion auf www.mosd.net gibt's dieses Beispiel auch als Visual Studio Projekt zum runterladen und rumexperimentieren!
Oder direkt über diesen Link:
http://www.mosd.net/de/full/fr_cmol_down.html

Helium schrieb:

Was bedeutet "starke Modularisierung durch Zentralisierung semantisch gleichartiger Codefragmente".

Mit semantisch gleichartigen Codefragmenten meinte ich ähnliche Codeteile, wie beispielsweise Flaechenberechnungsfunktionen. Flächen für verschiedene geometrische Objekte berechnen sich auch unterschiedlich (wie z.B. die Fläche eines Rechtecks verglichen mit der eines Kreises), dennoch sind sie semantisch gleichartig, da sie ja etwas "identisches" tun, trotz unterschiedlicher Implementierung.
Durch MOP und das Denken in Methoden werden solche Codeteile zentralisiert, was bedeutet, dass sie gebündelt an einer Stelle im Code zu finden sind. Würde man beispielsweise diese Flächenberechnungsmethoden in jeder von einer Basisklasse für geometrische Objekte abgeleiteten Klasse implementieren, würde dadurch eine "Streuung" von Code entstehen, der aus semantischer Sicht eigentlich zusammen gehört.
Entwickelt man in Methoden entsteht dadurch also eine sehr starke Modularisierung, da man in einem abgeschlossenen Programmmodul wirklich auch nur Code findet, der inhaltlich zusammengehört. Alle semantisch unterschiedlichen Inhalte eines Softwareprojektes sind so sehr klar voneinander getrennt.

Helium schrieb:

Und die Methodenorientierung schein sich erst bei komplexen Aufgaben zu lohnen. Denn bei einfachen:

Da ist sicher was dran. Je umfangreicher ein Softwareprojekt, desto schwieriger wird es Codestreuung zu vermeiden und je größer die Prologe und Epiloge in den Methoden und je häufiger diese Methoden vererbt werden, desto größer natürlich auch die Codeeinsparung.

SendKey

@Gregor:

Gregor schrieb:

Wenn ich das richtig verstanden habe, dann soll MOP ja besonders dann etwas bringen, wenn man wenige, semantisch gleiche Dinge mit vielen unterschiedlichen Arten von Objekten macht, wobei sich die Objekte selbst möglichst stark semantisch von einander unterscheiden.

Das die Objekte sich möglichst stark voneinander unterscheiden ist meiner Meinung nach nicht unbedingt wichtig.

Gregor schrieb:

1. Ist das richtig?

Ansonsten ja.

Gregor schrieb:

2. Wo kommt soetwas vor?

Eigentlich ständig. Es kommt zum Beispiel überall da vor, wo sehr viele Klassen von einer Basisklasse abgeleitet werden. Fast immer geht es dabei ja um die Implementierung einer oder mehrerer abstrakter Methoden. Da hat man bereits gleichartige Operationen, die auf viele verschiedene Objekte angewendet werden. Die Idee von C-mol besteht eben darin, das System nach diesen Methoden aufzudröseln um eine Zentralisierung von ählichen und Zusammenfassung von identischen Codeteilen zu schaffen, statt diese Methoden in die verschiedenen Klassen "einzustreuen".
Ebenso kommt dies bei der Erweiterung von Bibliotheken vor: Z.B. wenn es darum geht bestimmte Klassen um eine Funktionalität zu erweitern, ist es oft einfacher eine Methode mit Handlings für alle zu erweiternden Klassen anzulegen, als durch ableiten von der Basisklasse eine eigene Klassenhierarchie aufzubauen oder von allen abgeleiteten Klassen, deren Funktionalität man erweitern möchte abzuleiten.

Für eine "allumfassende" und meiner Meinung nach auch praxisnahe Übersicht über die Anwendungsfälle von C-mol und MOP ist denke ich die 12-seitige Overview ganz gut (ist allerdings auf Englisch). Hier der Link:

http://www.mosd.net/files/MOP-Overview.pdf

HumeSikkins

Hallo,
zum eigentlichen Thema kann ich nichts sagen, deshalb nur eine kleine Anmerkung:

Korbinian schrieb:

mal schauen, ob ich das programm verstanden hab. hier mal eine shortened version in c++:

void Epilog()
{
    // blablablub
}

void Prolog()
{
    // blablablub
}

/* Einzige aenderung: Geraet1 und Geraet2 werden von der gleichen basisklasse abgeleitet, 
die die gleichen members haben. müssen die gleichen sein, sonst würde der code ja nicht fuer beide hinhauen */

void EigentlicheFunktion(Geraet1_2Base *g)
{
    Prolog();
    // blablablubb
    Epilog();
}
[...]

[...]

3. Du musst immer daran denken, den Prolog und den Epilog aufzurufen.

In solchen Fällen würde ich wohl eher zum DP Template-Method tendieren:

class Drehbar
{ 
public:
    void drehe(int grad) {prolog(); doDrehe(); epilog();}
protected:
   virtual void doDrehe() = 0;
private:
    void prolog()
    {
        printf("Drehen beginnt...\n"); 
    }
    void epilog()
    {
        printf("Drehen endet.\n\n"); 
    }
}; 

class Rad : public Drehbar 
{ 
protected:
    void doDrehe() {printf("Ich dreh voll am Rad!\n");}
}; 

void f(Drehbar* p)
{
    p->drehe(60);
}

Alternativ kann man natürlich auch ein "Execute-Around"-Proxy-SmartPtr schreiben.

Wie auch immer, das explizite Aufrufen von Prolog/Epilog ist sicher keine schöne Lösung.

Cortex

@HumeSikkins:
Aus echtem Interesse: Von dem Aufwand abgesehen, dass ein C-mol-Compiler installiert und aktiviert werden muss (das ist ja ein technisches Problem, davon sehe ich jetzt mal ab und es wird ja vielleicht in Zukunft auch nicht mehr existent sein): was findest du an dem DP-Ansatz schoener? Er ist doch definitiv etwas schlechter zu lesen als eine methodenorientierte Loesung, da nicht so klar und sauber, oder?

c++eus

jetzt mal ein paar Fragen:
die Methodenorientierte Programmierung stützt sich doch hauptsächlich auf mit dem Schlüsselwort

method

eingeleitete Methoden. Diese besitzen einen Prolog und einen Epilog, die mit cem Kon- und Destruktor von Klassen zu vergleichen sind, und ja z.B. die gleiche Syntax besitzen (Gleicher name wie methode, ~,...). Des weiteren wird die Methode mit verschiedenen Prozeduren ausgestattet, die für verschiedene Dateitypen impletiert werden. Habe ich das alles richtig verstnden? Ist die Methodenorientierte Programmierung also eine "Typenunabhängige Lösung", die aber entgegen der Programmierung mit Templates mit anderen impletierungen für die jeweiligen Typen arbeiten? Im Gegensatz zu den verschiedenen Codes in C++ in diesem Threat soll die Methodenorientierung also zusammenfassen, was zusammengehört, oder? Verbessert mich bitte.

HumeSikkins

was findest du an dem DP-Ansatz schoener?
Er ist doch definitiv etwas schlechter zu lesen als eine methodenorientierte Loesung, da nicht so klar und sauber, oder?

Wenn du meinen Beitrag genau liest, wirst du feststellen, dass ich die DP-Lösung nicht mit C-mol in Verbindung gesetzt oder verglichen habe. Ich habe lediglich darauf hingewiesen, dass es auch in "klassischen" Sprachen wie C++ eine *saubere* Möglichkeit gibt, einen Pro- und Epilog *automatisch* ausführen zu lassen.

Ich habe mich noch nicht mit dem eigentlichen Thema dieses Threads beschäftigt, insofern kann ich wohl schlecht eine Aussage bezüglich schöner oder besser treffen. Auf den ersten Blick scheint es mir aber so, dass man diese "ein Prolog/Epilog, mehrere Methoden"-Geschichte gut mit Mixin-Klassen bzw. Proxy-SmartPointern nachbilden kann. Zumindest in C++, da diese Sprache Mehrfachvererbung sowie Operatorüberladung unterstützt.

Aber wie gesagt: ich habe mich mit dem Thema noch nicht beschäftigt.

SendKey

@c++eus:
Ja, ich denke Du hast das Prinzip richtig verstanden!
Der Prolog einer Methode wird immer vor jedem Handling ausgeführt, der Epilog immer nach jedem Handling der Methode. Handlings sind dabei das, was Du als Prozeduren bezeichnest. Also quasi "Behandlungsprozeduren" für einen bestimmten Datentyp.
Die syntaktischen Ähnlichkeiten in C-mol sind dabei so gewählt, dass die Syntax für einen C++ Programmierer möglichst intuitiv und leicht erlernbar sein soll. Das gilt auch für die Verberbung von Methoden, Polymorphismus, etc.

c++eus schrieb:

Ist die Methodenorientierte Programmierung also eine "Typenunabhängige Lösung", die aber entgegen der Programmierung mit Templates mit anderen impletierungen für die jeweiligen Typen arbeiten?

Ja, so kann man es sehn. Dabei besteht für den Fall das tatsächlich für einige Datentypen identische Implementierungen vorgesehn sind auch die Möglichkeit diese in Multihandlings zusammenzufassen. Außerdem sind auch Template-Handlings möglich (wird allerdings erst mit den nächsten Compilerversionen unterstützt).

c++eus schrieb:

Im Gegensatz zu den verschiedenen Codes in C++ in diesem Threat soll die Methodenorientierung also zusammenfassen, was zusammengehört, oder?

Ja, das ist genau richtig!
Ähnlicher Code soll zentralisiert werden, mehrfach implementierter Code soll eliminiert werden (durch Prolog/Epilog und Aufleitung von Methoden).

c++eus

@SendKey: Vielen Dank. Jetzt weis ich auch, was in der Dokumentation als Handlings bezeichnet wurde. Jetzt, da ich es verstanden habe, finde ich dieses Prinzip eigentlich ganz gut.

Bashar

SendKey: Kann es sein, dass C-mol eine Neuerfindung von CLOS (Common Lisp Object System) ist?

Cortex

HumeSikkins schrieb:

Wenn du meinen Beitrag genau liest, wirst du feststellen, dass ich die DP-Lösung nicht mit C-mol in Verbindung gesetzt oder verglichen habe. Ich habe lediglich darauf hingewiesen, dass es auch in "klassischen" Sprachen wie C++ eine *saubere* Möglichkeit gibt, einen Pro- und Epilog *automatisch* ausführen zu lassen.

Ack, die Moeglichkeit existiert natuerlich. Ich hatte nur herausgehoert, dass du sie auch bevorzugen wuerdest. Das ist dann eben eine Frage der Lesbarkeit...

Korbinian

das worauf ich (und vielleicht hume) hinaus wollten: gibt es einen triftigen grund, diese erweiterung herzunehmen? von c nach c++ hab ich klassen. das ist verdammt hart in c zu emulieren. dieses methoden-dings ist ja erwiesenermasen leicht zu emulieren.
nochwas: bei mehrfach abgeleiteten klassen, bei denen eine virtuelle methode immer wieder gleich implementiert werden muss, ist ein konstruktionsfehler, denn dann muss die funktion doch nicht virtual sein. wäre sie virtual und als solche immer anders implementiert, so ist kein gewinn gegenüber c-mol, denn da müsste man auch alle medhoden neu definieren. sind nur teile der funktion gleich, so kann man diesen auslagern, und dann in der abgeleiteten methode einfach über die super-klasse ansprechen.

ab und zu, gerade bei ablaufprogrammen (vgl. fliesband mit verpacker), könnte soetwas schon praktisch sein. aber wie gesagt: wie steht's mit der aufwand - nutzen - relation? brauhc ich einen neuen/erweiterten c++ compiler, eine schulung für mein team auf c-mol? oder sag ich ihnen in einer kurzen teambesprechung: so jungs, die funktionen müssen in ein DP Template geklatscht werden (und alle kennen sich aus)

c++eus

@Korbian: Du hast recht: Auch wenn die Erweiterungen in manchen (speziellen) Fällen ganz nützlich sein können, aber das wiegt wohl nicht die Probleme, Fragen ... einer neuen Programmiersprache bzw. sogar Standards auf.

Helium

OK, Team A schreibt ein Programm. Jenny schreibt eine Klasse "Drehtuer", Peter eine Klasse "Drehstuhl". Beide implementieren HumeSikkins "Drehbar". Nun können instanzen beider Objekte wuderbar gedreht werden und arbeiten auch mit allem zusammen, was Drehbarkeit erfordert.

Team B hat die selbe Aufgabe. Allerdings soll es das ganze MO implementiert sein. Auch hier gab es jemand, der schonmal was drehbares geschrieben hat.

method Drehen (int grad) {
   void prolog ()
   {
      cout << "gleich wird gedreht\n"
   }
   void epilog ()
   {
      cout << "und das war's\n"
   }
   void <Rad> ()
   {
      ...
   }

};

Und jetzt will Elke etwas für ihre Drehtür und Bob etwas für seinen Drehstul. Was machen sie? Leiten Sie jeweils eine Methode auf? Sie können doch wohl kaum an der Originalmethode rumpfuschen.

Korbinian

wir waren uns ja schon einig, dass irgenwie kaum sinnvolle beispiele zu finden sind du müsstest eher von einem prozeduralem programmtyp ausgehen. also so ne art fliesbandabarbeiter.

Helium

Genau das ist mein Problem. ICh finde keine Beispiele in meinen Problemen, wo ich die MO einsetzen kann. Das kann aber auch daran liegen, dass ich noch nicht MO denken kann.

Oh und das mit den Mulithandlern hatte ich total falsch verstanden.

cih dachte ein void<Foo, Bar>() könnte ich als Methode()°(foo, bar)() aufrufen und deshalb als dispatcher missbrauchen. Aber es heißt, das der eine Handle sowohl für Foo, als auch für Bar-objekte funktioniert.

SendKey

@Heluim:
Sicher könnten die beiden in dem Fall beide eine Methode aufleiten, was aber keine schöne Lösung wäre. Das wäre eine Art C++ Lösung, die man in C-mol geschrieben hat. Ist das Projekt methodenorientiert geplant worden, wäre eine Person mit der Entwicklung aller Drehroutinen und damit mit der Entwicklung der Dreh-Methode beauftragt. Somit wären eben alle gleichartigen Routinen bei einer Person.

@Korbinian:
Ja, es mag sein, dass die C-mol-Erweiterungen wirklich mit C++ leichter nachzubilden sind, als C++ mit C. Wobei es denke ich bei intensiver Nutzung von Methodenvererbung, etc. Mit der "Staffelung" der Prologe und Epiloge auch nicht mehr so ganz einfach werden dürfte. Allerdings (hatte ich ja schon mal angesprochen) liegt die Stärke eines Entwicklungssystems ja nicht nur in den Vorteilen der technischen Realisierung sondern vor allem auch darin, dass diese Vorteile automatisch entstehen, wenn man ein solches System anwendet.
Zum Beispiel gibt es auch Möglichkeiten funktionale Progammieransätze in einer imperativen Sprache nachzubilden. Ich kann beispielsweise explizit bei der Entwicklung mit einer imperativen Sprache darauf achten (wie auch in der Funktionalen Programmierung), das Programmieren mit Seiteneffekten zu vermeiden. Allerings entsteht dieser Vorteil implizit, wenn ich das Programm gleich in einer funktionalen Sprache (wie z.B. Scheme) entwickle und "funktional" Denke.
Mit anderen Worten: Verwende ich C-mol muss ich bei der Entwicklung nicht explizit verhindern, dass Coderedundanzen und Codestreuungen, etc. entstehen. Es kommt automatisch nicht vor, wenn ich methodenorientiert denke!

Was den Umstand sich in eine Erweiterung/neue Sprache einzuarbeiten angeht:
Da ist natürlich auch was dran. Aber ich denke mit C-mol ist es schon relativ einfach, die methodenorientierten Konzepte einzusetzen: Sowohl die Syntax wie auch die "semantischen" Regeln sind alle (fast) identisch wie in C++ und daher denke ich sehr "intuitiv" für C++ Programmierer anzuwenden.
Außerdem kann man C-mol ja (wie gasagt) auch nur sehr gezielt einsetzen. Man kann ja trotzdem alle C++ Konstrukte verwenden und nur dort, wo es sinnvoll ist, methodenorientiert arbeiten. Der C-mol Compiler verarbeitet ja auch C++ Code oder man kann auch nur die methodenorientierten Module C-mol-compilieren.

Aber allgemein ist es natürlich richtig, dass es geeignetere und ungeeignetere Probleme für C-mol gibt.

@Bashar:
Nein, ich denke CLOS ist eher eine "Objektorientierung für Lisp", oder?

Korbinian

SendKey schrieb:

Mit anderen Worten: Verwende ich C-mol muss ich bei der Entwicklung nicht explizit verhindern, dass Coderedundanzen und Codestreuungen, etc. entstehen. Es kommt automatisch nicht vor, wenn ich methodenorientiert denke!

das ist genau der punkt: c-mol nimmt mir den denkschritt ab, den ich bei c++ machen muss, nämlich das stete aufpassen, dass ich nicht sachen öfters schreibe, indem es mich ja permanent erinnert, generische sachen in den epi- und prolog zu klatschen. wenn man aber ein weitsichtiger programmierer ist, erkennt man gleiche sachen im voraus, und kann sie gleich zusammenfassen.

Was ist z.b., wenn ich nicht nur einen pro- und epilog brauche, sondern auch zwischendurch einen abschnitt haben, der für alle zielklassen gleich ist. wie komme ich denn in c-mol weiter? muss ich dann 2 methoden definieren?

Und eben nochmal zum hauptproblem: (Fast) jede gängige Programmiersprache(nerweiterung) hat einen "aufwand" legitimierenden grund, z.b. Java wenn ich plattformübergreifend schnell ein programm mit grafischer oberfläche haben will, pascal/c wenn ich nur prozedural arbeiten muss, etc.
Bei c-mol ist das ganze so speziell, dass es kaum beispiele gibt, wo man es anwenden kann. wozu also diese spracheerweiterung lernen, wenn man sie eh pauschal gesagt nicht brauchen kann, man muss bei sowas immer den zeit/nutzen aufwand sehen: wieviel zeit brauche ich, um das konzept und die spracherweiterung drin zu haben, und was fuer einen nutzen hab ich davon.
es wäre mir sehr geholfen, wenn du 2-3 beispiele bringen könntest, wo c-mol super reinpasst, und die aber auch häufige programmierprobleme/aufgaben sind.

ps: noch was: ich wage zu behaupten, dass in dem drehbar beispiel die c++ variante sauberer und übersichtlicher ist.

edit:

SendKey schrieb:

Ist das Projekt methodenorientiert geplant worden, wäre eine Person mit der Entwicklung aller Drehroutinen und damit mit der Entwicklung der Dreh-Methode beauftragt. Somit wären eben alle gleichartigen Routinen bei einer Person.

uff. nimm mal ein projekt mit 100 klassen. dann muss ja der methodenentwickler alle 100 klassen im kopf haben! viel sinnvoller wäre es, wenn jeder entwickler den speziellen teil zu seiner klasse selbst zur verfügung stellt, und einer die generischen teile erstellt, und die speziellen nur durchsieht. das würde sich aber in gewisser weise nicht mit mo-entwicklung decken.

Bashar

SendKey schrieb:

@Bashar:
Nein, ich denke CLOS ist eher eine "Objektorientierung für Lisp", oder?

Naja, schon, aber ich meinte eher die Idee dahinter. Im Gegensatz zu den üblichen OO-Sprachen, in denen man eine Klasse definiert und ihr einen festen Satz Methoden spendiert, sind die beiden Aspekte in CLOS getrennt.
Genau (anscheinend jedenfalls) wie in C-mol definiere ich die Methoden als zugehörig zu einer "generischen Funktion", etwa so:

(defgeneric area (obj))

(defmethod area ((obj circle))
  (* pi (square (radius obj))))

(defmethod area ((obj square))
  (square (side obj)))

(area (make-instance 'square :side 5))
==> 25

Den Prologen und Epilogen entsprechen dabei :before bzw. :after-Methoden.

(defmethod area :before ((obj square))
  (princ "Prolog von area (square)"))

junix

Ich hab mich mit dem Konzept noch nicht beschäftigt, sondern nur diesen Thread gelesen. Dieser allerdings birgt für mich eine ganz wichtige Erkenntnis die Bashar gemacht hat: Er erkennt parallelen zu einem Sprachmittel einer anderen Sprache... Ich finde den Punkt insofern interessant, als das man dadurch vermuten könnte, dass sich hier ein (vl. umsteiger?) die Mühe gemacht hat ein ihm bekanntes Mittel nachzubilden, weil C++ ihm das nichtmehr bietet und er sich mit den restlichen Mitteln nicht auskennt? (nur so eine Theorie)

Wenn ich mir den Thread hier so durchlesen, dann fällt mir ebenfalls auf, dass man wirklich nur mit ach und krach irgend ein Beispiel zusammenzimmern kann.. von was sinnvollem gar nicht zu reden.

-junix

SendKey

Korbinian schrieb:

das ist genau der punkt: c-mol nimmt mir den denkschritt ab, den ich bei c++ machen muss, nämlich das stete aufpassen, dass ich nicht sachen öfters schreibe, indem es mich ja permanent erinnert, generische sachen in den epi- und prolog zu klatschen. wenn man aber ein weitsichtiger programmierer ist, erkennt man gleiche sachen im voraus, und kann sie gleich zusammenfassen.

Ja, das ist in der Theorie richtig. In der Praxis meiner Meinung nach oft nicht richtig machbar.

Korbinian schrieb:

Was ist z.b., wenn ich nicht nur einen pro- und epilog brauche, sondern auch zwischendurch einen abschnitt haben, der für alle zielklassen gleich ist. wie komme ich denn in c-mol weiter? muss ich dann 2 methoden definieren?

In diesem Fall sollte man entweder Multihandlings für die entsprechenden Klassengruppen definieren, oder mit Methodenvererbung arbeiten.

Korbinian schrieb:

Und eben nochmal zum hauptproblem: (Fast) jede gängige Programmiersprache(nerweiterung) hat einen "aufwand" legitimierenden grund, z.b. Java wenn ich plattformübergreifend schnell ein programm mit grafischer oberfläche haben will, pascal/c wenn ich nur prozedural arbeiten muss, etc.
Bei c-mol ist das ganze so speziell, dass es kaum beispiele gibt, wo man es anwenden kann. wozu also diese spracheerweiterung lernen, wenn man sie eh pauschal gesagt nicht brauchen kann, man muss bei sowas immer den zeit/nutzen aufwand sehen: wieviel zeit brauche ich, um das konzept und die spracherweiterung drin zu haben, und was fuer einen nutzen hab ich davon.
es wäre mir sehr geholfen, wenn du 2-3 beispiele bringen könntest, wo c-mol super reinpasst, und die aber auch häufige programmierprobleme/aufgaben sind.

Gut, meiner Meinung nach hab ich ja schon versucht einige solcher Beispiele zu bringen. Allerdings wurden diese dann immer in C++ umgeschrieben. Wie gesagt, meiner Meinung nach ist es nicht "natürlich" so zu arbeiten. Ist es nicht viel geschickter nach semantischen Gesichtspunkten zu entwickeln ohne große Gedanken an die technische Umsetzung zu verschwenden und der Rest entsteht durch das System "automatisch"? Eigentlich sollte das doch einfacher sein, als sich ständig darüber Gedanken machen zu müssen, wie ich überflüssige Mehrfachimplementierungen vermeide.

Korbinian schrieb:

ps: noch was: ich wage zu behaupten, dass in dem drehbar beispiel die c++ variante sauberer und übersichtlicher ist.

Ich persönlich nicht, aber für mich greift hier das gleiche Argument wie obendrüber beschrieben. Wird eine Dreh-Methode entwickelt, so ergibt sich automatisch, was sinnvollerweise in Prolog und Epilog ausgelagert werden sollte. Es muss nicht explizit daran gedacht werden. Außerdem befasst sich dann auch ein Programmierer mit dem gleichen Typ von Routinen!

Korbinian schrieb:

uff. nimm mal ein projekt mit 100 klassen. dann muss ja der methodenentwickler alle 100 klassen im kopf haben! viel sinnvoller wäre es, wenn jeder entwickler den speziellen teil zu seiner klasse selbst zur verfügung stellt, und einer die generischen teile erstellt, und die speziellen nur durchsieht. das würde sich aber in gewisser weise nicht mit mo-entwicklung decken.

Nein, eigentlich nicht, er muss nur die semantisch gleichartigen Teile der Klassen im Kopf haben; und auch nur die der Klassen, die von seiner Methode verarbeitet werden. So muss ein Programmierer beispielsweise nicht wissen, welche Dateihandles eine Klassengruppe besitzt, wenn er eine Dreh-Methode für die Klassen implementiert.
Wohingegen der objektorientierte Programmierer sehr viel mehr von einer abgleiteten Klasse verstehen muss, wenn er alle verschiedene (abstrakte) Methoden implementieren will. Man trennt in der MOP eben nach "klassenübergreifenden Gemeinsamkeiten".

Wenn in der OOP Programmierer Klassen ableiten um ihre speziellen Klassen zu implementieren, muss jeder Programmierer Ahnung von dem haben, was er implementieren soll. Das kann unter Umständen heißen, dass sich mehrere Programmierer damit beschäftigen müssen, wie man die Klasse in eine Datei schreibt, wie man sie dreht, wie man sie visualisiert, etc.
In der Methodenorientierung hätte man einen Programmierer für jeden dieser Funktionalitäten. Der Programmierer, der sich um die Drehalgorithmik kümmert, muss keine Einblicke in die Klassenteile haben, die für das Drehen uninteressant sind. So sind die Gebiete der einzelnen Programmier sehr von einander getrennt, was weniger Schnittstellendefinitionen, etc. erfordert.