Parser/Grammatiken: Konstruktoren

Kellerautomat

Xin schrieb:

Wäre es da nicht positiv, wenn man diese Besonderheit auch im Quelltext herausstellt?

Das versuche ich doch mit ().

Xin schrieb:

Deswegen setze ich hier auf 'construct'. Es ist eindeutig suchbar und muss nicht angepasst werden, wenn sich der Name der Klasse ändert.

Zuerst war ich bei "constructor", aber das war mir zu lang, also bin ich zunaechst bei "ctor" gelandet. Das schien mir aber zu kurz. Dann hab ich mich gefragt "Wozu ueberhaupt so ein Konstrukt?" und bin jetzt bei ().

Uebrigens danke fuer das Erwaehnen der Suchbarkeit. Ueber diesen Aspekt des Sprachdesigns habe ich noch gar nicht nachgedacht.

Xin

Kellerautomat schrieb:

Xin schrieb:

Wäre es da nicht positiv, wenn man diese Besonderheit auch im Quelltext herausstellt?

Das versuche ich doch mit ().

Ich bin sicher, dass das optisch schon herausragen kann.

Während ich allerdings dagegen ankämpfe nicht in Prosa zu verfallen, um einigen kryptischen Elementen entgegen zu wirken, erscheint mir das jedoch dann doch etwas einsam im Raum stehend, auch wenn ich es soweit gut nachvollziehen kann und auch in einer gewissen Weise als elegant empfinde.

Kellerautomat schrieb:

Xin schrieb:

Deswegen setze ich hier auf 'construct'. Es ist eindeutig suchbar und muss nicht angepasst werden, wenn sich der Name der Klasse ändert.

Zuerst war ich bei "constructor", aber das war mir zu lang, also bin ich zunaechst bei "ctor" gelandet. Das schien mir aber zu kurz. Dann hab ich mich gefragt "Wozu ueberhaupt so ein Konstrukt?" und bin jetzt bei ().

ctor und dtor sind zu nah zusammen, optisch wie auch auf den meisten Tastaturen. Man vertippt sich schnell. constructor ist zwar lang, aber eindeutig. Sogar so eindeutig, dass man es nicht wiederverwenden kann. So kam ich zu 'construct'.
Wobei das letzte Wort da noch nicht gesprochen ist, vielleicht wird es auch ein 'create', was sich allerdings vom üblichen Sprachgebrauch "Konstruktor" entfernen würde.

Kellerautomat schrieb:

Uebrigens danke fuer das Erwaehnen der Suchbarkeit. Ueber diesen Aspekt des Sprachdesigns habe ich noch gar nicht nachgedacht.

Suchbarkeit und leichte Interpretierbarkeit von Sprachen sind relativ junge Probleme im Sprachdesign. Schließlich muss heutzutage nicht nur der Entwickler eine Sprache lesen, auch ein Editor wünscht sich da klare und möglichst einfach zu implementierende Regeln vorfinden.

GyroGearloose

Xin schrieb:

So kam ich zu 'construct'.
Wobei das letzte Wort da noch nicht gesprochen ist, vielleicht wird es auch ein 'create', was sich allerdings vom üblichen Sprachgebrauch "Konstruktor" entfernen würde.

Ich fände ein eigenes Schlüsselwort bzw. einen speziellen Methodennamen für Konstruktoren/Destruktoren aufgrund der Konsistenz mit normalen Methodendefinitionen auch besser.

Mir gefallen construct / destruct gut, denn create / destroy benutzt man doch gerne für (unter Umständen statische) Factory- und Ressourcenmanager-Methoden. Außerdem ist es ja gemeinhin guter Stil, den Imperativ im Sinne von doSomething() für die Bennenung von Methoden zu verwenden ( construct vs. constructor ).

das Problem stammt letztendlich von inkonsequenter Auffassung von Objektorientierung.

bei konsequenter Anwendung der OO-Prinzipien stellt sich das Problem eigentlich gar nicht: Eine Klasse ist dann ein Objekt - Instanz der zugehörigen Metaklasse nämlich - und Instanzen werden erzeugt, indem eine Methode, sagen wir: "new", der Klasse aufgerufen wird: MyClass.new(...) oder MyClass new: ...

ruby und "new style classes" in python haben das auf syntaktischer Ebene mit myClass.new(...) bzw myClass.__new__(...)

Shade Of Mine

buchstaben schrieb:

bei konsequenter Anwendung der OO-Prinzipien stellt sich das Problem eigentlich gar nicht: Eine Klasse ist dann ein Objekt - Instanz der zugehörigen Metaklasse nämlich

und metaklasse sind instanzen der zugehoerigen metametaklasse?

Michael E.

Shade Of Mine schrieb:

und metaklasse sind instanzen der zugehoerigen metametaklasse?

Nein, sie sind Instanzen von sich selbst.

http://ruby-doc.org/core-1.9.3/Class.html

Shade Of Mine schrieb:

und metaklasse sind instanzen der zugehoerigen metametaklasse?

ja.

und damit endet die Meta-Hierarchie auch schon, weil Meta-Metaklassen Instanzen von Metaklasse sind - d.h. weil "Metaclass class" eine Instanz von sich selbst ist

Michael E.

buchstaben schrieb:

Shade Of Mine schrieb:

und metaklasse sind instanzen der zugehoerigen metametaklasse?

ja.

und damit endet die Meta-Hierarchie auch schon, weil Meta-Metaklassen Instanzen von Metaklasse sind - d.h. weil "Metaclass class" eine Instanz von sich selbst ist

Wo genau brauchst du die Meta-Metaklasse?

Antoras

Man könnte den ctor direkt an den Klassennamen heften und den dtor in den Klassenrumpf stopfen, z.B.:

class X protected (a: Int, b: Int) extends Y(a+b) {
  doSomething()
  doMore()
  dtor {
    ...
  }
  ...
}

Alles im Klassenrumpf wird im ctor ausgeführt, bis auf den dtor natürlich.

Michael E. schrieb:

Wo genau brauchst du die Meta-Metaklasse?

weil bei konsequenter Auslegung des Objektprinzips Metaklassen ihrerseits Objekte sind, es also eine Klasse geben muß, deren Instanzen Metaklassen sind: die Meta-Metaklasse

Michael E.

buchstaben schrieb:

Michael E. schrieb:

Wo genau brauchst du die Meta-Metaklasse?

weil bei konsequenter Auslegung des Objektprinzips Metaklassen ihrerseits Objekte sind, es also eine Klasse geben muß, deren Instanzen Metaklassen sind: die Meta-Metaklasse

Und die Meta-Metaklasse identifizierst du dann mit der Metaklasse? OK, als theoretische Definition machts Sinn. Ich hatte gedacht, du wolltest in der tatsächlichen Implementierung eine eigene Meta-Metaklasse (ungleich der Metaklasse) einführen.

Edit: Ich bin etwas verwirrt von den Begriffen, um ehrlich zu sein

es gibt Programmiersprachen, in denen die Meta-Metaklasse tatsächlich vorkommt ("Metaclass class")

da funktioniert beispielsweise so was:

String class isMemberOf: Metaclass.
"true"

Metaclass class isMemberOf: Metaclass.
"true"

letzteres ist der Zirkelschluß, der eine unendliche Meta-Hierarchie verhindert.

Bashar

Wieso windest du dich eigentlich so darum, das Wort Smalltalk in den Mund zu nehmen? Weil "konsequente Auslegung des Objektprinzips" wissenschaftlicher klingt?

Zeus

Bashar schrieb:

Wieso windest du dich eigentlich so darum, das Wort Smalltalk in den Mund zu nehmen? Weil "konsequente Auslegung des Objektprinzips" wissenschaftlicher klingt?

Weil er sich nicht als unsere alter Smalltalk-Lover outen will xD

Bashar schrieb:

Wieso windest du dich eigentlich so darum, das Wort Smalltalk in den Mund zu nehmen? Weil "konsequente Auslegung des Objektprinzips" wissenschaftlicher klingt?

Weil es z.B. in Ruby genauso ist wie in Smalltalk.

Bashar

Michael E. logged out schrieb:

Bashar schrieb:

Wieso windest du dich eigentlich so darum, das Wort Smalltalk in den Mund zu nehmen? Weil "konsequente Auslegung des Objektprinzips" wissenschaftlicher klingt?

Weil es z.B. in Ruby genauso ist wie in Smalltalk.

Das ist kein Grund.