Ctor einer Klasse aufrufen, die so heißt wie eine Methode

[BeRsErKeR]

Folgendes Szenario:

Code: Alles auswählen

class position { ... };

class area
{
public:
class position position(void) const{return Position;}
class position foo(int x, int y){return class position(x, y);} // <--- Problem

private:
class position Position;
};

Es geht hier um die markierte Zeile (Methode foo). Ich möchte hier einfach ein lokales Objekt erstellen und es zurückgeben. Allerdings meckert der g++ hier. Man kann scheinbar das Schlüsselwort class so nicht verwenden. Lasse ich "class" weg, meckert er, weil er annimmt, dass ich die Methode position meine. Ich könnte mir zwar lokal ein Objekt erstellen und dieses dann zurückgeben, allerdings habe ich die Befürchtung, dass der Compiler das dann nicht so gut wegoptimieren kann.

Gibts da eine spezielle Syntax mit der das geht? Ich weiß man sollte hier einfach die Methode position umnennen, aber ich möchte die Interfaces nun mal konsistent halten. In der Positionsklasse, kann man z.B. auch die Methode x() aufrufen und dass position gleichzeitig Name und Typname sind ist eher Zufall und wird nicht die Regel sein.

[Sternmull]

Das sollte sich durch einen qualifizierten Namen lösen lassen, also z.B. "::position" wenn die Klasse "position" im globalen Namensbereich ist. Ansonsten halt so was wie "::someNamespace::position". Aber ehrlich gesagt würde ich ein Namensschema empfehlen das die Kollision von Klassen- und Methodennamen ausschließt. Das liest sich sonst sehr schlecht weil man immer erst Kontextwissen (umgebende Namensbereiche, using-Direktiven, Basisklassen etc.) braucht und dann ein bisschen Compiler spielen muss um herauszufinden ob nun eine Klasse oder eine Methode gemeint ist.

[Krishty]

typedef class position positionType;
return positionType(x, y);
Momentan ohne Zugriff auf einen Compiler; darum geraten.

Gruß, Ky

[BeRsErKeR]

Das sollte sich durch einen qualifizierten Namen lösen lassen, also z.B. "::position" wenn die Klasse "position" im globalen Namensbereich ist. Ansonsten halt so was wie "::someNamespace::position". Aber ehrlich gesagt würde ich ein Namensschema empfehlen das die Kollision von Klassen- und Methodennamen ausschließt. Das liest sich sonst sehr schlecht weil man immer erst Kontextwissen (umgebende Namensbereiche, using-Direktiven, Basisklassen etc.) braucht und dann ein bisschen Compiler spielen muss um herauszufinden ob nun eine Klasse oder eine Methode gemeint ist.

Die Probleme hat man in der Regel nur innerhalb der Lib, da nach außen hin eh der namespace vorangestellt werden muss und daher z.B. position absolut nicht bekannt ist, sondern nur namespace::position. In der Regel sind bei mir Typen stets groß geschrieben, allerdings wollte ich in diesem Projekt konsistent zur STL bleiben und Standardtypen sind ja auch klein geschrieben. Bei Methoden/Funktionen möchte ich mich an unix-basierten Libs wie z.B. gtkmm orientieren, wo diese meist klein geschrieben sind und ggf. mit Unterstrich getrennt.

[kaiserludi]

wieso nicht einfach gettern ein get vorranstellen, also getPosition(), statt position()?

[Krishty]

wieso nicht einfach gettern ein get vorranstellen, also getPosition(), statt position()?

Es verrät zu viel über die Interna.

Wenn eine Methode getXXX() heißt, dann erwarte ich, dass sie den Wert tatsächlich in annähernd O(0) aus dem Speicher liest. Ich erwarte dann außerdem, dass dann ebenfalls alle Methoden, die den Wert erst berechnen müssen bzw. eine Laufzeit O(>=1) haben, computeXXX() heißen. (Aber außer mia scheint absolut niemand einen Scheiß auf die Unterscheidung zu geben.)

Bei freien Funktionen ist das äußerst sinnvoll, weil man einem Aufruf sofort ansieht, wann man etwas neu berechnet haben möchte und wann einem ein altes Ergebnis ausreicht. Bei Objekten hingegen würde es verraten, welche Daten intern als Attribute vorliegen und welche erst aus Attributen berechnet werden müssen, und würde dadurch die Abstraktion verletzen.

Darum bloß weg damit aus Klassen.

(Man merkt mia meine Fundamentalprogrammierung an.)

[BeRsErKeR]

(Aber außer mia scheint absolut niemand einen Scheiß auf die Unterscheidung zu geben.)
...
(Man merkt mia meine Fundamentalprogrammierung an.)

Um ehrlich zu sein finde ich solche Überlegungen sehr lobenswert. Die meisten würden an sowas nicht mal denken. Das Problem ist halt, dass es da keine gängigen Standards oder Vorschriften gibt und so kocht jeder sein eigenes Süppchen. Und andere führen dann unüberlegte Quasi-Standards ein, wie damals die MFC, wo selbst heute noch viele denken, man müsse ein großes C vor einen Klassennamen schreiben.

Ich würde mir z.B. auch viel striktere Namenskonventionen und Syntaxvorgaben wünschen und ehrlich gesagt auch Einrückungen als Syntaxelement wie in Python. Das würde die Codestruktur vereinheitlichen und fremder Code wäre viel einfacher lesbar und eindeutiger. Ich glaube allerdings nicht, dass in diese Richtung etwas kommen wird.

Allerdings bin ich ehrlich gesagt schon seit vielen Jahren auf der Suche nach guten Namenskonventionen und finde das Thema recht interesaant. Vielleicht kann ich ja was von dir lernen was das angeht. Man denkt halt auch nicht an alles. Wie handhabst du denn so im Groben deine Typnamen, Membernamen, etc pp?

[dot]

(Aber außer mia scheint absolut niemand einen Scheiß auf die Unterscheidung zu geben.)

Ah, du bist nicht allein. Ich bekomm sogar körperliche Schmerzen wenn ich irgendwo eine Methode seh, deren Name mit get beginnt ;)

[Schrompf]

Naja, ihr seid schon nahezu allein mit der Einstellung.

[kaiserludi]

wieso nicht einfach gettern ein get vorranstellen, also getPosition(), statt position()?

Es verrät zu viel über die Interna.

Wenn eine Methode getXXX() heißt, dann erwarte ich, dass sie den Wert tatsächlich in annähernd O(0) aus dem Speicher liest. Ich erwarte dann außerdem, dass dann ebenfalls alle Methoden, die den Wert erst berechnen müssen bzw. eine Laufzeit O(>=1) haben, computeXXX() heißen. (Aber außer mia scheint absolut niemand einen Scheiß auf die Unterscheidung zu geben.)

Bei freien Funktionen ist das äußerst sinnvoll, weil man einem Aufruf sofort ansieht, wann man etwas neu berechnet haben möchte und wann einem ein altes Ergebnis ausreicht. Bei Objekten hingegen würde es verraten, welche Daten intern als Attribute vorliegen und welche erst aus Attributen berechnet werden müssen, und würde dadurch die Abstraktion verletzen.

Darum bloß weg damit aus Klassen.

(Man merkt mia meine Fundamentalprogrammierung an.)

In meinen Augen sind getter einfach ein Ersatz für Properties in Sprachen, die nicht über das Sprachfeature Properties verfügen. Man nimmt man sich entweder die Freiheit, die Implementation von Properties und damit auch Gettern als Interna zu sehen und somit auch Berechnugnen zu erlauben oder aber, man muss Properties in dieser Hinsicht die Abstraktion verletzen lassen, in dem man verlangt, dass sie immer bereits vorhandene Variablen zurückgeben. Für was würdest du dich in C# bei Properteis entscheiden? Entsprechendes kannst du dann mit der gleichen Begründung auch in C++ amchen und die Methoden dort ruhigen Gewissens mit get im Namen beginnen lassen. Wer aber ein get im Methodennamen in C++ für falsch hält und nur bei Funktionen angebracht, der muss konsequenterweise auch in Sprachen wie C# oder auch objC ab 2.0, die über Properties verfügen, sich weigern, irgendetwas zu verwenden, was Properties benutzt, was im Grunde bedeutet, das man diese Sprachen komplett verdammen muss. Würdest du so weit gehen?

[BeRsErKeR]

wieso nicht einfach gettern ein get vorranstellen, also getPosition(), statt position()?

Es verrät zu viel über die Interna.

Wenn eine Methode getXXX() heißt, dann erwarte ich, dass sie den Wert tatsächlich in annähernd O(0) aus dem Speicher liest. Ich erwarte dann außerdem, dass dann ebenfalls alle Methoden, die den Wert erst berechnen müssen bzw. eine Laufzeit O(>=1) haben, computeXXX() heißen. (Aber außer mia scheint absolut niemand einen Scheiß auf die Unterscheidung zu geben.)

Bei freien Funktionen ist das äußerst sinnvoll, weil man einem Aufruf sofort ansieht, wann man etwas neu berechnet haben möchte und wann einem ein altes Ergebnis ausreicht. Bei Objekten hingegen würde es verraten, welche Daten intern als Attribute vorliegen und welche erst aus Attributen berechnet werden müssen, und würde dadurch die Abstraktion verletzen.

Darum bloß weg damit aus Klassen.

(Man merkt mia meine Fundamentalprogrammierung an.)

In meinen Augen sind getter einfach ein Ersatz für Properties in Sprachen, die nicht über das Sprachfeature Properties verfügen. Man nimmt man sich entweder die Freiheit, die Implementation von Properties und damit auch Gettern als Interna zu sehen und somit auch Berechnugnen zu erlauben oder aber, man muss Properties in dieser Hinsicht die Abstraktion verletzen lassen, in dem man verlangt, dass sie immer bereits vorhandene Variablen zurückgeben. Für was würdest du dich in C# bei Properteis entscheiden? Entsprechendes kannst du dann mit der gleichen Begründung auch in C++ amchen und die Methoden dort ruhigen Gewissens mit get im Namen beginnen lassen. Wer aber ein get im Methodennamen in C++ für falsch hält und nur bei Funktionen angebracht, der muss konsequenterweise auch in Sprachen wie C# oder auch objC ab 2.0, die über Properties verfügen, sich weigern, irgendetwas zu verwenden, was Properties benutzt, was im Grunde bedeutet, das man diese Sprachen komplett verdammen muss. Würdest du so weit gehen?

Also ich persönlich halte von C# genauso viel wie von Java, nämlich gar nichts. Und ich halte auch nichts von Properties. Allerdings muss das jeder für sich entscheiden.

[Krishty]

@BeRsErKeR: Danke :)

Allerdings bin ich ehrlich gesagt schon seit vielen Jahren auf der Suche nach guten Namenskonventionen und finde das Thema recht interesaant. Vielleicht kann ich ja was von dir lernen was das angeht. Man denkt halt auch nicht an alles. Wie handhabst du denn so im Groben deine Typnamen, Membernamen, etc pp?

Tut mir leid; ich kann da nichts Ausgereiftes bieten. Grob benenne ich Typnamen (inklusive Namensbereichen) in großem CamelCase; Instanznamen in kleinem; private Attribute bekommen ein my davor. Ich kollidiere selber oft (z.B. habe ich hier gerade ein Attribut, das class heißen müsste -.-) und für meine Gedanken zu Interpretierbarkeit, Entropie und Namensraum ist es heute schon zu spät.

Ah, du bist nicht allein. Ich bekomm sogar körperliche Schmerzen wenn ich irgendwo eine Methode seh, deren Name mit get beginnt ;)

Wenn meine Schmerzen doch bloß körperlich wären … danach sehne ich mich manchmal …

In meinen Augen sind getter einfach ein Ersatz für Properties in Sprachen, die nicht über das Sprachfeature Properties verfügen.

Meine Meinung von Properties ist niedrig. Ich akzeptiere sie schon lange nicht mehr als Sprach-Feature, sondern als Sprachballast, weil sie keine Funktionalität hinzufügen. Je mehr ich über das Konzept nachdenke, desto weniger kann ich es mit Kapselung, Abstraktion und Minimalismus vereinen. Mehr noch; gerade diese Diskussion hinterlässt bei mir den Eindruck, dass sie eine reine Syntaxabkürzung für Entwürfe sind, die

1. nicht ausreichend zwischen Objekten und Daten unterscheiden; deshalb
2. viel zu viele Attribute haben; und
3. bei denen sich darum pro Attribut viel zu wenig Gedanken gemacht wurden und man auch zum Einsatz von weniger Arbeit bereit ist.

was im Grunde bedeutet, das man diese Sprachen komplett verdammen muss. Würdest du so weit gehen?

Es dürfte mittlerweile bekannt sein, dass ich C++ nicht einsetze, weil ich es gut finden würde, sondern, weil es am wenigsten scheiße ist. (Und wegen ein paar exklusiven Features.) Mit C# habe ich noch nicht gearbeitet; nach dem, was ich bisher weiß, will ich das auch nicht (aus kräftigeren, Java-mäßigeren Gründen als nur wegen der Properties).

[Chromanoid]

Ich finde die Standard Java Coding Conventions ziemlich gut - auch für andere Sprachen. Methoden groß schreiben, wie im C# Standard finde ich unschön. Der AS3 Standard lehnt an den von Java an. Private Member speziell zu markieren mag ich nicht, es scheint sich dafür aber in AS3 und C# '_' durchzusetzen, in Java ist das ja nicht wirklich nötig, da man nicht gleichnamige Properties hat.

[dot]

In meinen Augen sind getter einfach ein Ersatz für Properties in Sprachen, die nicht über das Sprachfeature Properties verfügen.

Meine Meinung von Properties ist niedrig. Ich akzeptiere sie schon lange nicht mehr als Sprach-Feature, sondern als Sprachballast, weil sie keine Funktionalität hinzufügen. Je mehr ich über das Konzept nachdenke, desto weniger kann ich es mit Kapselung, Abstraktion und Minimalismus vereinen. Mehr noch; gerade diese Diskussion hinterlässt bei mir den Eindruck, dass sie eine reine Syntaxabkürzung für Entwürfe sind, die

1. nicht ausreichend zwischen Objekten und Daten unterscheiden; deshalb
2. viel zu viele Attribute haben; und
3. bei denen sich darum pro Attribut viel zu wenig Gedanken gemacht wurden und man auch zum Einsatz von weniger Arbeit bereit ist.

Prinzipiell ist das auch meine Meinung genau auf den Punkt gebracht. Wobei ich vereinzelte read-only Properties ok find. Aber spätestens wenn eine Property ein Get und ein Set hat, hat man imo ein Designproblem. Ich hab mir jedenfalls schon vor langer Zeit implizite Functioncalls für C++ gewünscht, afaik existiert sogar ein Proposal für genau sowas. Damit könnte ich meiner Mathelibrary endlich HLSL-Style Swizzling beibringen...

was im Grunde bedeutet, das man diese Sprachen komplett verdammen muss. Würdest du so weit gehen?

Es dürfte mittlerweile bekannt sein, dass ich C++ nicht einsetze, weil ich es gut finden würde, sondern, weil es am wenigsten scheiße ist. (Und wegen ein paar exklusiven Features.) Mit C# habe ich noch nicht gearbeitet; nach dem, was ich bisher weiß, will ich das auch nicht (aus kräftigeren, Java-mäßigeren Gründen als nur wegen der Properties).

C# ist eigentlich eine sehr schöne Sprache. Schaus dir mal an, ich glaub du würdest es mögen ;)

[CodingCat]

C# ist eigentlich eine sehr schöne Sprache. Schaus dir mal an, ich glaub du würdest es mögen ;)

I happen to know enough about garbage collection to not want it.

;)

[dot]

Ja das stimmt, der Zwang zur Garbage Collection ist imo eine der großen Schwächen von C# auf Sprachebene. Nichtdeterministischer Scope ist für die Mehrzahl der Fälle einfach eine völlig bescheuerte Idee...

[BeRsErKeR]

Ich frage mich schon eine Weile ob OO-Aspekte wirklich Teil der Programmiersprache sein sollten. Eine Klasse könnte man z.B. theoretisch in einer Art Meta-Sprache oder xml-ähnlichen Sprache deklarieren, genauso wie Vererbung und damit verbundene Hierarchien. Daher wäre ich fast für eine Trennung zwischen "Designsprache" und "Funktionssprache". In letzterer arbeitet man nur noch mit Instanzen und kann Methoden und Objekte referenzieren, während die Beschreibung von Klassen usw in einer anderen Sprache erfolgt. Damit könnte man (im Falle von xml-ähnlichen Sprachen) auch recht einfach Applikationsübersichten und Dokumentationen erstellen ohne z.B. Umwege über Kommentare (wie z.B. bei doxygen). Ich frage mich warum das alles so fest verwurzelt im Code ist, obwohl es dafür mMn keinen Grund gibt.

[Chromanoid]

Aber warum XML 0_o? XML ist doch widerlich sobald es etwas mehr wird. Klassen passen doch wunderbar in den Code. Was wäre denn der Unterschied zu einer Deklaration in XML. Sicher als C++er ist man eine Art Trennung gewohnt und eine Analyse ist nur schwer möglich, aber das liegt an C++ und nicht an den Klassen. Bei Java kann man sich einfach in den Kompilierungsprozess einklinken und Analysemöglichkeiten sind sozusagen im Compiler mit eingebaut. Ähnliches gilt afaik für .Net.
Wenn du deine Klassen mit XML definieren willst, kannst du es ja mal versuchen. Mit einem XSLT Prozessor könntest du den Code dann wohl recht einfach daraus generieren. Ich stelle mir das grauenhaft vor, ich finde die Trennung ja schon in C++ und ObjC behindernd... Inwiefern würde denn eine Dokumentation wegfallen? Das gleiche müsste man dann doch in der XML schreiben.

[BeRsErKeR]

Tut mir leid. Ich hab mich glaube ich nicht ganz verständlich ausgedrückt. Ich bin keineswegs ein Fan von xml. Ich wollte nur sagen, dass man Klassen, Hierarchien usw auch in beliebigen anderen Sprachen beschreiben kann und dass es meiner Meinung nach nicht wirklich "Code" ist, sondern eher ein "Design". Es geht mir auch nicht darum, dass man da getrennte Dateien hat, sondern vielmehr, dass Klassendeklarationen usw vereinfacht werden könnten und nicht unbedingt der Syntax des "eigentlichen Codes" folgen müssten. Eine relativ simple Beschreibungssprache würde für den ganzen OO-Kram ausreichen und die Bodies von Funktionen könnten dann mit komplexerem Code gefüllt sein. Solche Designs könnte man z.B. auch in einer grafischen Sprache unabhängig von der Implementierungssprache anfertigen. Ich will eigentlich nur ausdrücken, dass für mich diese beiden Sachen zwei paar Schuhe sind und deshalb nicht zwangsläufig den gleichen Syntaxregeln folgen oder in gleichen Sprachen geschrieben werden müssen.

[Chromanoid]

Mmh naja jede Sprache hat ja ihre eigene Syntax für Klassen. Es ist einfach schlechtes Sprach-Design oder ein Mangel im Compiler, wenn man sich mit den Keywords ins Gehege kommen kann.

[kaiserludi]

Tut mir leid. Ich hab mich glaube ich nicht ganz verständlich ausgedrückt. Ich bin keineswegs ein Fan von xml. Ich wollte nur sagen, dass man Klassen, Hierarchien usw auch in beliebigen anderen Sprachen beschreiben kann und dass es meiner Meinung nach nicht wirklich "Code" ist, sondern eher ein "Design". Es geht mir auch nicht darum, dass man da getrennte Dateien hat, sondern vielmehr, dass Klassendeklarationen usw vereinfacht werden könnten und nicht unbedingt der Syntax des "eigentlichen Codes" folgen müssten. Eine relativ simple Beschreibungssprache würde für den ganzen OO-Kram ausreichen und die Bodies von Funktionen könnten dann mit komplexerem Code gefüllt sein. Solche Designs könnte man z.B. auch in einer grafischen Sprache unabhängig von der Implementierungssprache anfertigen. Ich will eigentlich nur ausdrücken, dass für mich diese beiden Sachen zwei paar Schuhe sind und deshalb nicht zwangsläufig den gleichen Syntaxregeln folgen oder in gleichen Sprachen geschrieben werden müssen.

Schau dir mal objC an:
Die gesamte Objekt-Orientierung ist in Smalltalk geschrieben und wird durch bestimmte Marker vom Rest des Codes, welcher C ist, abgegrenzt.
Der Gesamtcode wird dann durch einen sperziellen objC Preprozessor gejagt, welcher den ganzen OO-Code in C umwandelt, bevor er an den ganz normalen C Preprozessor und dann den ganz normalen C-Compiler weitergegeben wird.
Ist im Grunde doch genau das, was du willst: Das Design ist in einer eigenen Sprache mit einfacher Syntax, die nichts mit der Sprache zu tun hat, in der der eigentliche low-level Code ist und dann geparst und automatisch in echten Code übersetzt wird.

[BeRsErKeR]

Hat sicher seine Reize, leider auch eine viel zu kryptische Syntax. Wenn ich schon sehe, dass manche Typen kleingeschrieben werden und andere komplett groß, dann denk ich mir, next. Also es geht in gewisser Weise in die Richtung, aber ist zu unleserlich für meinen Geschmack. Da ist es in C++ ja noch übersichtlicher.

[kaiserludi]

Hat sicher seine Reize, leider auch eine viel zu kryptische Syntax. Wenn ich schon sehe, dass manche Typen kleingeschrieben werden und andere komplett groß, dann denk ich mir, next. Also es geht in gewisser Weise in die Richtung, aber ist zu unleserlich für meinen Geschmack. Da ist es in C++ ja noch übersichtlicher.

Die Typen haben System in der Schreibweise:
small: standard c
BIG: Makro
CFCamelCase: CoreFoundation (Apple C-framework)
NSCamelCase: Foundation (Apple objC Framework)
Kryptisch sieht der Code manschmal schon aus, insbesondere wenn man es ausweitet auf objC++ mit inline asm, aber auch nicht viel schlimmer als in C++, ist eine reine Gewöhnungssache. Das neue Memory Managment seit iOS5/osx10.7 ist ziemlich genial (Automated Reference Counting zur Kompilierzeit, performanter als wenn man es selbst macht, aber so einfach wie mit GC) und seit Xcode 4 gibts auch eine halbwegs taugliche IDE. Da hat sich in letzter Zeit echt vieles zum guten gewandelt.
Ich finde C++ immer noch deutlich besser, aber das liegt an anderen Dingen als der Syntax, nämlich einfach an generellen Schwächen von objC: Sehr schwache Typisierung zur Kompilierzeit, wenn Typen offensichtlich nicht passen, interessiert das dennoch oft erst die Runtim, keine Konsturktoren/Destruktoren, sodnern nur explizit aufzurufenden init und release, bei denen sich jeder daran halten muss, was Methoden mti diesen Namen machen, damit keine Grütze raus kommt, keine privaten Methoden, kein protected, keine freidns, keine Namespaces, keine multiple Vererbung, keine Templates, ja nicht mal generics, die Standardbibliothekt stellt keine typsicheren Container zur Verfügung, die Performance von vielen elementaren Funktionalitäten wie eifnachen Methodenaufrufen ist selsbt im best case deutlich schlechter als sie in C++ im worst-case ist, usw.

[dot]

Ich frage mich schon eine Weile ob OO-Aspekte wirklich Teil der Programmiersprache sein sollten. Eine Klasse könnte man z.B. theoretisch in einer Art Meta-Sprache oder xml-ähnlichen Sprache deklarieren, genauso wie Vererbung und damit verbundene Hierarchien. Daher wäre ich fast für eine Trennung zwischen "Designsprache" und "Funktionssprache". In letzterer arbeitet man nur noch mit Instanzen und kann Methoden und Objekte referenzieren, während die Beschreibung von Klassen usw in einer anderen Sprache erfolgt.

Kurz gesagt willst du also das Typsystem aus der Sprache entfernen? Das macht imo keinen Sinn. Was genau sollte denn ein "arbeiten mit Objekten und Methoden" bedeuten, in einer Sprache, die kein Konzept von Typen hat!? Das wäre doch wie sprechen in einer Sprache, die nur Prädikate kennt...
Abgesehen davon: Sobald du von "Objekt" und "Methode" sprichst, bist du doch schon im Reich der OOP unterwegs!?

Wenn ich schon sehe, dass manche Typen kleingeschrieben werden und andere komplett groß, dann denk ich mir, next.

Ich halte es normal so, dass Typen mit Wertsemantik klein geschrieben werden. Ich find sowas wie Vector, Matrix etc. einfach absolut unästhetisch. Und wenn man mal sowas wie std::vector<BigObject> sieht, weiß man sofort, dass irgendwo was kaputt ist...

[BeRsErKeR]

Ich frage mich schon eine Weile ob OO-Aspekte wirklich Teil der Programmiersprache sein sollten. Eine Klasse könnte man z.B. theoretisch in einer Art Meta-Sprache oder xml-ähnlichen Sprache deklarieren, genauso wie Vererbung und damit verbundene Hierarchien. Daher wäre ich fast für eine Trennung zwischen "Designsprache" und "Funktionssprache". In letzterer arbeitet man nur noch mit Instanzen und kann Methoden und Objekte referenzieren, während die Beschreibung von Klassen usw in einer anderen Sprache erfolgt.

Kurz gesagt willst du also das Typsystem aus der Sprache entfernen? Das macht imo keinen Sinn. Was genau sollte denn ein "arbeiten mit Objekten und Methoden" bedeuten, in einer Sprache, die kein Konzept von Typen hat!? Das wäre doch wie sprechen in einer Sprache, die nur Prädikate kennt...
Abgesehen davon: Sobald du von "Objekt" und "Methode" sprichst, bist du doch schon im Reich der OOP unterwegs!?

Nö ich beschreibe nur den Aufbau einen Typs nicht in der selben Sprache, in der ich ihn nutze. Den Typ int oder float kann ich auch nutzen ohne dass ich den Aufbau in C++ schreiben muss. Ein Typ soll schon zur Sprache gehören, nicht aber wie dieser Typ designed wird. Quasi nur das Endprodukt. Es wäre völlig ausreichend wenn ich den Typ position nutzen könnte und den Aufbau dieses Typs in einer "Designsprache" erstelle.

Methoden und Operatoren bilden dann halt das Interface eines Typs. Genauso wie ein int z.B. die Operatoren für Addition usw aufweist. Denkbar wären auch typgebundene Methoden für den Typ int, wie z.B. size(), max(), min() usw (ähnlich wie std::numeric_limits das anbietet aber halt nicht direkt als Typmethoden).

Die eigentliche Sprache, die ich dann für wirklichen Code verwende, kann sich dann auf Berechnungen und Programmstrukturen konzentrieren und muss nicht mal das Konzept einer Klasse oder das der Vererbung kennen.

Die Designsprache hätte außerdem den Vorteil völlig unabhängig von der Implementierung zu arbeiten, sprich sie wäre völlig unabhängig vom Betriebssystem, vom Compiler oder der Runtime, selbst von den meisten Compilereinstellungen (z.B. Debug). Man könnte Großteile der Sprache und des Programms also ohne Mehraufwand plattformunabhängig entwickeln.

Als Kernsprache könnte man sogar einfach C nehmen. Die Designsprache könnte prinzipiell sehr vielfältig sein. Auszeichnungssprachen, grafische Sprachen usw.

[dot]

Also wenn du mich fragst klingt mir das eher nach einer Sprache mit einfach nur stark unterschiedlicher Syntax für Deklarationen und Definitionen/Statements. Schau dir mal das schon erwähnte Objective-C an, das geht wohl in die Richtung...

[BeRsErKeR]

Nenn es wie du willst. Es macht keinen Unterschied. Allerdings können die beiden (Teil-)Sprachen unabhängig voneinander arbeiten, daher könnte man für das Design auch verschiedene Sprachen nutzen, wenn der Compiler der Kernsprache die richtigen Informationen rüberreicht. Und auch die Kernsprache könnte prinzipiell beliebig sein. Die Design-Sprache muss diese nicht einmal kennen.

[dot]

Also ich hab irgendwie den Eindruck, dass wenn man diese Idee zu Ende denkt, .NET dabei rauskommt ;)

[BeRsErKeR]

Also ich hab irgendwie den Eindruck, dass wenn man diese Idee zu Ende denkt, .NET dabei rauskommt ;)

Naja nur halt schöner, schneller, einfacher und besser. ;)