programmierBar

In so gut wie jeder dynamischen Sprache kann man Objekte zur Laufzeit manipulieren. Selbst in Java geht das. Mit ging es jetzt auch nicht darum einen Anfänger mit irgendwelchen Feinheiten zu erschlagen, oder auf Definitionen herumzuhacken aber gerade deine Definition fand ich zu speziell. Die Unterscheidung zwischen Programmcode und dem Code der zur Laufzeit ausgeführt wird finde ich bei der Grunddefinition von OOP-Begriffen etwas zu weitgehend, das das wie gesagt nur Implementierungsdetails sind.
Und gerade bei dynamischen Sprachen mit JIT-compiler kann man sich nicht sicher sein, dass das was im Programmcode festgehalten ist, auch wirklich das ist, was später zur Laufzeit erzeugt wird(s. hidden classes bei Googles V8).

Eine Quelle muss ich nicht liefern, da selbst dein Zitat aus dem Smalltalk-Buch meine Definitionen bestätigt.
Da sind wir wohl anderer Meinung. :)

Edit: Einziger Unterschied: deine Quelle unterscheidet nicht zwischen Objekt und Objektinstanz bzw finde ich die Beschreibung sehr unsauber. Was unterscheidet hier Objekt und Instanz? Wozu eine sprachliche Unterscheidung, wenn es eigentlich das gleiche ist?
Alle Objekte sind Instanzen ihrer Klasse. Das dient nur zur Unterscheidung ob man gerade von irgendwelchen Objekten spricht oder von denen die zu der Klasse gehören die man gerade erwähnt hat.
Was ist das Ding im Programmcode, das noch nicht instanziiert wurde? Ist das eine Klasse? Ist das ein Objekt. Beides passt nicht so recht.
Da alles in Smalltalk ein Objekt ist und alle Objekte Instanzen ihrer Klasse sind, gibt es demnach nichts im Programmcode, das nicht instanziiert wurde (zumindest theoretisch, aus Geschwindigkeitsgründen wird die eine oder andere Optimierung vorgenommen allerdings hat man bei Bedarf Zugriff auf jeden einzelnen Bytecode einer Methode). Und Klassen sind wie gesagt Instanzen ihrer Metaklasse.

Edit2: Nimmt man an, dass Private Memory Speicher des Programms ist, welches nicht "aktiv" (sprich ohne Zustand) ist, stimmt auch meine Definition wieder. Instanzen sind dann eine Kopie der Objekte mit Zustand. Übersehe ich etwas?
Bis auf Ausnahmen(z.B. GNU Smalltalk) sind die Implementierungen vom Smalltalk meist Image-basiert. Die Images sind nichts weiter als Speicherabbilder der Virtuellen Maschine in denen das Programm abläuft, also ja, alle Objekte haben einen Zustand und wenn das Programm nicht läuft wird er im Image gespeichert.
 
Wir reden definitiv aneinander vorbei!

ich les mir das bis morgen mal in Ruhe durch, um deine Begriffswelt in meine zu übersetzen.
 
Hmpf. Wozu schreib ich mir eigentlich die Finger wund. Klassen sind die textuelle Beschreibung, die Vorlage, auch bei Objective C! Du öffnest einen Editor und notierst dort das Aussehen des Objektes in Form von einer Klasse! Diese wird dann vom Compiler übersetzt und es liegt ein Objekt im Programmcode vor. Das wird dann zur Laufzeit instanziiert! Das alles gilt auch für Objective C und Smalltalk!

Aeh...ich programmier zwar auch schon ein paar Jahre, aber bisher hab ich auch nur zwischen Instanz und Klasse unterschieden.

Wenn man das auf Java umlegt, was ist dann das "Object" von dem du sprichst? Das Objekt der Klasse selbst? Dh. wenn ich zb. auf ein static field zugreife, greife ich aufs Objekt zu (ich hab frueher der Einfachheit "Klasse" dazu gesagt) ... *g*.
 
Aeh...ich programmier zwar auch schon ein paar Jahre, aber bisher hab ich auch nur zwischen Instanz und Klasse unterschieden.

Wenn man das auf Java umlegt, was ist dann das "Object" von dem du sprichst? Das Objekt der Klasse selbst? Dh. wenn ich zb. auf ein static field zugreife, greife ich aufs Objekt zu (ich hab frueher der Einfachheit "Klasse" dazu gesagt) ... *g*.

Jein, das Objekt ist teil des Programmcodes, des Bytecodes if you will (ob auf der Platte oder im Speicher). An dem Objekt wurde noch nicht der Construktor gerufen, es ist also nicht initialisiert. In Java sorgt aber der Ruf an einer statischen Method dafür, dass die class-Datei geladen und der Static Constructor gerufen wird. Es existiert als genau eine Instanz. Diese Instanz ist in diesem Fall ein Singleton: wann immer man die statische Methode ruft, ruft man sie an diser einen erzeugten Instanz. Der Static Constructor wird nur ein mal zur Laufzeit, während des Ladens ausgeführt. Danach hat das Objekt einen Zustand.

Ich gebe zu, die von mir geschilderte Unterscheidung ist im Grunde theoretisch und akademischer Natur und dient eher der Klarstellung des Zustandsbegriffs.
 
  • Gefällt mir
Reaktionen: Shizuma
In so gut wie jeder dynamischen Sprache kann man Objekte zur Laufzeit manipulieren. Selbst in Java geht das.

Oh, Objekte zur Laufzeit manipulieren. Ich schmeiß mal in den Raum, dass das Evil ist und nur von sehr unsauberem Stil zeugt. Man hat sich in dem Fall während der Designphase nicht genug Gedanken gemacht, wie was auszusehen hat. In meinen Augen bricht das auch mit einem der heiligen Kühe der OO: dem Information Hiding und Kapseln. Um ein Objekt zur Laufzeit verändern zu können, benötige ich explizites Wissen über seine Interna. Trotzdem ändert sich dabei nicht mein Grundgedanke der Vorlage. Ein Teil steht dann eben nicht in der Definition der Klasse sondern codiert im Quellcode und später auch im Objekt. Ich treffe ja mit Absicht keine Aussage, wie eine Klasse definiert wird. Eine Klasse ist für mich nur ein Tupel aus einer möglicherweise leeren Menge an Variablen und einer möglicherweise leeren Menge an Methoden.


Die Unterscheidung zwischen Programmcode und dem Code der zur Laufzeit ausgeführt wird finde ich bei der Grunddefinition von OOP-Begriffen etwas zu weitgehend, das das wie gesagt nur Implementierungsdetails sind. Und gerade bei dynamischen Sprachen mit JIT-compiler kann man sich nicht sicher sein, dass das was im Programmcode festgehalten ist, auch wirklich das ist, was später zur Laufzeit erzeugt wird(s. hidden classes bei Googles V8).

Das sind eben keine Implementierungsdetails. Diese Betrachtung ist rein abstrakt und sagt weder etwas über das Aussehen der Klasse, noch der verwendeten Syntax noch etwas über den Zusammenhang zwischen Klasse und Objekt aus. Meine Definition sagt nur, dass aus einer wie auch immer gearteten Vorlage (Klasse) ein Objekt geschaffen wird, was wiederum Schablone für Instanzen ist.

Ob eine Sprache dynamisch ist oder nicht, hat übrigens absolut nichts damit zutun, ob man Objekte manipulieren kann. Du schreibst ja selbst, dass das auch mit Java geht und diese Sprache ist ja wirklich ein Musterbeispiel für statische Typisierung.

Alle Objekte sind Instanzen ihrer Klasse. Das dient nur zur Unterscheidung ob man gerade von irgendwelchen Objekten spricht oder von denen die zu der Klasse gehören die man gerade erwähnt hat.
Da alles in Smalltalk ein Objekt ist und alle Objekte Instanzen ihrer Klasse sind, gibt es demnach nichts im Programmcode, das nicht instanziiert wurde (zumindest theoretisch, aus Geschwindigkeitsgründen wird die eine oder andere Optimierung vorgenommen allerdings hat man bei Bedarf Zugriff auf jeden einzelnen Bytecode einer Methode). Und Klassen sind wie gesagt Instanzen ihrer Metaklasse.

Bis auf Ausnahmen(z.B. GNU Smalltalk) sind die Implementierungen vom Smalltalk meist Image-basiert. Die Images sind nichts weiter als Speicherabbilder der Virtuellen Maschine in denen das Programm abläuft, also ja, alle Objekte haben einen Zustand und wenn das Programm nicht läuft wird er im Image gespeichert.

Das sind alles Smalltalk-Konzepte. Die Sprache hat, das wirst du zugeben, einen recht weit gefassten OO-Begriff. Es wird dort ja auch von einem 5-Tier-OO gesprochen (classes, classes-classes, meta-classes, object-classes, objects). Das Eine instantiiert das Nächste, das vorgehende ist Schablone für das Nachfolgende. Sicherlich wäre mein Ansatz hier nur wenig hilfreich. Bei dem OO-Ansatz von GTK, C++, ObjC, Java, Python, PHP, Objective Pascal und vielen mehr ist er es aber.

Nachtrag: Verstehe ich das richtig? Der Compiler erzeugt ein voll initialisiertes Image in dem alle jemals zur Laufzeit verwendeten Objekte bereits fertig initialisiert vorliegen? Das halte ich für eine unglaubliche Speicherverschwendung. Wenn dem nicht so ist, werden (nach meiner Nomenklatur) Instanzen erzeugt, die einen Zustand haben. Dass man diese jetzt als Image abspeichern kann, tut dabei nichts zur Sache. Das geht mit Java auch (zb mit Hibernate, wobei dort interessanterweise zu beobachten ist, dass beim zrückladen eine neue Instanz mit den alten Werten erzeugt wird. Sowohl die Objekt-ID als auch der Speicherbereich sind nicht die selben).
 
Zuletzt bearbeitet:
Oh, Objekte zur Laufzeit manipulieren. Ich schmeiß mal in den Raum, dass das Evil ist und nur von sehr unsauberem Stil zeugt.
„Monkeypatching“ oder Mixins sind zumindest bei Python und Ruby Gang und Gäbe. Bei Javascript gehts es ja gar nicht anders und die categories von ObjC gehen in eine ähnliche Richtung. Ob das unsauber ist oder nicht, da könnte man endlos drüber streiten, benutzt wird es zumindest. Aber irgendwie gleiten wir jetzt sehr vom Thema ab. ;)

Das sind eben keine Implementierungsdetails. Diese Betrachtung ist rein abstrakt und sagt weder etwas über das Aussehen der Klasse, noch der verwendeten Syntax noch etwas über den Zusammenhang zwischen Klasse und Objekt aus. Meine Definition sagt nur, dass aus einer wie auch immer gearteten Vorlage (Klasse) ein Objekt geschaffen wird, was wiederum Schablone für Instanzen ist.
Zur Klasse, wenn du „in textueller Form“ streichst bin ich einverstanden. Zum Objekt, für mich sind Objekte keine Schablonen für Instanzen sondern selbst die Instanzen. Was auch in der Smalltalkdefinition zu finden ist. Zwischen Instanzen und Klassen noch eine Zwischenschicht einschieben zu wollen verwirrt nur und zudem können als sie mir Anwender recht egal sein, davon kriegt man eh nichts mit, also warum erwähnen?

Das sind alles Smalltalk-Konzepte. Die Sprache hat, das wirst du zugeben, einen recht weit gefassten OO-Begriff. [...] Sicherlich wäre mein Ansatz hier nur wenig hilfreich.
Klar ist Smalltalk eine sehr idealistische Sprache, allerdings halte ich es für wenig sinnvoll (OOP-) Begrifflichkeiten zu definieren, die für die Sprache, die mit den größten Einfluß auf OOP hatte, nicht zutreffen.

Nachtrag: Verstehe ich das richtig? Der Compiler erzeugt ein voll initialisiertes Image in dem alle jemals zur Laufzeit verwendeten Objekte bereits fertig initialisiert vorliegen? Das halte ich für eine unglaubliche Speicherverschwendung.
Nein natürlich nicht, wie gesagt wird das Konzept durch Optimierungen gebrochen. Ich kenne mich nicht 100% in den Interna der VM auf aber viele Objekte werden erst erstellt, wenn man sie anfordert, die Bytecodes werden z.B. kaum als ein voll initialisiertes Array von Integer-Objekten vorliegen, sondern einfach als Speicherblock. Aber die Hauptsache ist, dass das für den Anwender völlig transparent ist, ihm wird nichts anderes als ein Objekt über den Weg laufen. Zum Speicherverbrauch: Das aktuelle Pharo-Image ist 16 MB groß und verbraucht ~ 30 MB Ram und da ist wohlgemerkt eine komplette Entwicklungsumgebung dabei.
 
Zuletzt bearbeitet:
Ich glaube, wir reden mal wieder mit unterschiedlicher Sprache über die selben Dinge. Belassen wir es dabei, da ein sauberer Disput hier zu weit führen würde. Smalltalk hat seine eigenen Definitionen für seinen OOP-Ansatz gefunden. Allen Gemein ist, dass es Vorlagen gibt, welche irgendwie in Objekte umgesetzt werden. Was schlussendlich als Objekte angesehen wird, ist von Sprache zu Sprache oder besser Ansatz zu Ansatz unterschiedlich.

Noch etwas: Ich muss zugestehen, dass ich von Smalltalk relativ wenig Ahnung habe. Bisher befasste ich mich primär mit den verbreitetsten Sprachen (C++, Java, PHP, Python, JS).

Lass uns hier einen Schlussstrich ziehen ;)
 
Smalltalk hat seine eigenen Definitionen für seinen OOP-Ansatz gefunden. Allen Gemein ist, dass es Vorlagen gibt, welche irgendwie in Objekte umgesetzt werden. Was schlussendlich als Objekte angesehen wird, ist von Sprache zu Sprache oder besser Ansatz zu Ansatz unterschiedlich.
Mein Punkt war eigentlich, dass das gerade nicht so ist und ich habe Smalltalk nur als Beispiel genommen,

Lass uns hier einen Schlussstrich ziehen ;)
aber du hast recht. :)
 
Ich würde gerne in meinen Code (Java sowie PHP) irgendwie meinen Namen reinschreiben und irgendwie freundlich zum Ausdruck bringen möchte, dass das mein Quelltext ist und ich gerne vorher gefragt werden würde, wenn den jemand anders verwendet.

Für mich selbst würde ich gerne noch das Jahr rein bringen.

Einfach

Code:
/* martinibook 2010
 * martinibook@localhost
 */

Oder gibt es da eventuell irgendwelche Standards?
 
Mir fällt Doxygen ein.

http://www.stack.nl/~dimitri/doxygen/

Schau dir an wie das dort gemacht wird. Ansonsten ist es üblich mit

Code:
/**
 * Some Text
 *
 * @author John Smith
 * @copyright © john.smith@me.com, 2010
 */

oder ähnlichem.
 
Vielleicht noch ein "All rights reserved." dazu.

Aber ich habe das Gefühl, da macht eh jeder wie er will. Halt sollte bloß klar sein, wer der Author des Dokumentes ist, "Copyright" sollte da stehen und noch irgendwie das Jahr.
 
Nicht nur Copyright sondern auch das Zeichen © - damit wird das "All Rights Reserved" implizit.
 
Gut, dann bastle ich das mal:

Code:
/**
 * Dieser Quelltext ist das geistige Eigentum von martinibook und darf nicht ohne Erlaubnis des Autors in irgendeiner Weise benutzt, verändert oder veröffentlicht werden.
 *
 * This source code is the intellectual property of martinibook and may not be used, modified or published in any way without permission by the author.
 *
 * @author martinibook
 * @copyright © martinibook@localhost, 2010, All Rights Reserved
 */

Oder ist das zu viel des Guten?
 
Ich muss mich von oben nochmal berichtigen. Da das Copyright nicht zur Dokumentation des Programms sondern zu den Dateien gehört, gehört das nicht in Document Strings (/** */) sondern in normale Kommentare ( // Text oder /* */ - ersteres zum optischen Abtrennen vllt besser geeignet)
 
"in irgendeiner Weise benutzt"
Dh jeder der es liest, macht sich strafbar? :D

In Deutschland is das so, dass Dir eh als Urheber von irgendwas das Urheberrecht zusteht. Das kann Dir keiner wegnehmen und beinhaltet quasi das gleiche.
 
Ja, gut, also die Formulierung lasse ich dann einfach weg.

Dann mache ich einfach ein

Code:
// Copyright (c) 2008 martinibook (martinibook@localhost)

rein und gut ist :)
 
Ich habe da doch nicht ernsthaft 2008 geschrieben, oder? :faint:

martinibook, wir sind in 2010! :D
 
Natürlich nicht. Aber wenn man irgendeine Emailadresse hinschreibt, wird der Inhaber der Domain mit Spam zugemüllt, weil die Emailadresse irgendwann abgegrast wird. Schreibt man @localhost, dann passiert das nicht, aber man erkennt es als Emailadresse.

Das "All Rights Reserved" kann man ja noch anhängen … wobei "Copyright" ja eigentlich auch alles sagt.
 
Natürlich nicht. Aber wenn man irgendeine Emailadresse hinschreibt, wird der Inhaber der Domain mit Spam zugemüllt, weil die Emailadresse irgendwann abgegrast wird. Schreibt man @localhost, dann passiert das nicht, aber man erkennt es als Emailadresse.

Deshalb kennt der Profi RFC 2606
und verwendet beispielsweise "@example.com"

Alex
 
Zurück
Oben Unten