Reflection

ihoernchen

witte schrieb:

Dieses Beispiel bezog sich nicht auf die aktuelle Auflösung, sondern alle, die diese Hardware unterstützt. Man könnte es im weiten Sinne so auffassen, dass es eine Schnittstelle "Auflösungsmodus" gibt, die von verschiedenen konkreten Auflösungstypen implementiert werden. Man könnte nun abfragen, welche solch implementierenden Typen in der Hadware/Treibersoftware exisitieren.
Aber Du scheinst recht zu haben, die Diskussion hat sich weit davon entfernt...

Ja stimmt. Das ändert jedoch nichts. Du kannst es auch durch "unterstützte Auflösungen" ersetzen. Auch das wäre keine reflection.

reflection ist nicht einfach das erfragen von Informationen.
Das scheint mir ein wesentliches Missverständnis zu sein.
Vielmehr geht es um die Art der Informationen.

ihoernchen

otze schrieb:

eine wirklich einfache form von reflection in C++ wär vielleicht sowas:

class Base
{
    public:
        virtual bool isSizeImplemented()=0;
        virtual int size()=0;
};
...

Base* obj=getObj();
if(obj->isSizeImplemented())//abfragen der strukturinformation
{
    cout<<obj->size();//abfragen des wertes
}
else
{
    cout<<"N/A";
}

Meiner Meinung nach wäre das keine reflection.
Ok, wie schon angesprochen ist das nun Haarspalterei und jeder wird es anders sehen.
Und dazu kommt ich durch java und C# vorgeschädigt

Hier (in deinem Beispiel) wird eher der "Funktionsumfang" beschrieben.
Der Unterschied ist, dass du dir als Programmierer aussuchen kannst diese Informationen zu liefern oder nicht; es ist Teil der Schnittstelle. Ok, du wirst sagen ich leite alles in meinem Programm von Base ab. Aber das ist kein Zwang.
Die über reflection zugändlichen Meta-Daten sind immer vorhanden (z.B. der Compiler generiert diese). Sie sind unabhängig von der Schnittstelle eines Objekts zugänglich.
Die Schnittstelle des Objekts ist Teil der Meta-Daten (also z.B. welche öffentlichen Methoden hat ein Objekt).

Das scheint sich mit dem Grafik-Beispiel zu beißen, gebe ich zu.

Wie gesagt, ich sehe es selbst so. Diese Ansicht ist sehr durch C# geprägt.

Jester

Shade Of Mine schrieb:

Jester schrieb:

Das wird vermutlich nicht klappen. Und das verlange ich auch garnicht. Aber es gibt jede Menge Programme über die man sich anhand der Definition einig ist, dass sie *kein* OOP sind.

selbes bei reflection.

Genau das sehe ich bei Deiner Definition nicht so. Aber das zu Hinterfragen ist ja eine bescheuerte und total irrelevante Frage.

vec.size() ist zB keine metainformation.

Aber eine Bildschirmauflösung natürlich schon? Die Grenze ist doch auch nicht weniger willkürlich als zu sagen, wenn ich eine externe Datei lade, ist das nicht sowas wie das ganze in mein Programm einbinden? Wird es damit evtl. zum Teil des Programms? Bei einem Grafiktreiber, den ich anspreche,würde ich sagen nein, der läuft unabhängig vom Programm, bei einem Plugin eher ja, das wird sozusagen zu einem Teil der Applikation.

genauso ist es nichtzwangsläufig reflection wenn informationen abgefragt werden.

Darüber sind wir uns wenigstens einig. Allerdings kann man meiner Meinung nach mit Deiner Definition von Reflection so ziemlich jede Abfrage von Information als Reflection einordnen. Sicher verstehst Du, dass ich unter dieser Prämisse Deine Definition ablehnen muß. Daher fragte und frage ich auch immer wieder in dieser bescheuerten Richtung nach, weil an dieser Stelle ganz offensichtlich unser Verständnis Deiner Definition auseinandergeht.

Du übergehst btw alle meine Argumente -> ist Reflection dadurch definiert ob ich die richtige oder die falsche Datei lade. Das ist nämlich der Grundstein deiner Definition: sobald ich eine externe Datei laden kann und Reflection verwende, fällt deine Definition um.

Ja, die übergehe ich, weil ich es für einen Nebenschauplatz halte. Du legst hier eine willkürliche und offensichtlich unpassende Definition von Programm an, um die Definition ad absurdum zu führen. Wie Du aber selbst angemerkt hast, ist diese Abgrenzung keineswegs fest und auch nicht 100% fest zu machen. Eine einzelne ungeschickte Interpretation macht also nichts kaputt.

Du stützt dich auf den 1. Satz in dem wikipedia Artikel (ohne den Rest und die Referenzen zu beachten):

In computer science, reflection is the process by which a computer program can observe and modify its own structure and behavior.

Ich sehe auch nicht, was man daran falsch verstehen kann. Vielleicht kannst Du's mir nochmal am Beispiel mit der Bildschirmauflösung und der Notrufsäule (oder was das nochmal war) erklären. Wer beobachtet und modifiziert da seine eigene Struktur? -- Meiner Meinung nach sind das beides keine Beispiele für Reflection.

Aber der Satz schließt nicht aus dass auch externe Resourcen - zB ein Plugin reflectiert werden kann. Die Code Samples verwenden tw externe Resourcen und in der Diskussion über den Artikel wird auch die umformulierung zu

More generally, reflection is an activity in computation that allows an object to have information about the structure and reason about its own computation.

Ja, das ist ein schöner Satz und er enthält auch wieder das "own". Um es mal so zu sagen: Der Artikel sagt Reflection ist folgendes: Wir haben ein A und A kann Reflection wenn A weiß wie A aufgebaut ist und wenn A A modifizieren kann. Weit und breit ist hier kein weiteres Objekt/Modul/whatever B zu sehen.

Deine Definition sagt: Reflection ist, wenn wir ein A haben und ein B und A von B Informationen über B bekommen kann.

Erstere Definition schließt ja keinesfalls aus, dass A die Informationen an jemanden anderes weitergibt, letztere fordert aber dass es noch jemanden gibt.

den anstoß oder die anfrage über diese metainformationen kann aber von extern kommen: schließlich ist interopabilität ein kernpunkt der programmierung.

ja, da stimme ich vollkommen zu.

Shade Of Mine schrieb:

Reflection bedeutet ja: ich frage eine blackbox nach informationen - da es eine blackbox ist, kann nur sie mir die information geben -> das nennt sich reflection.

ich habe die einzelnen standpunkte nicht alle im detail gelesen, und möglichweise sage ich jetzt etwas dummes oder redundantes, aber wäre nach dieser definition nicht bereits jede art der datenkapselung schon reflection?

wenn ich meine definition noch anbringen darf: reflection ist die bereitstellung von informationen über die eigene beschaffenheit (im gegensatz zu nutzdaten), zum zweck der interoperabilität mit anderen entitäten.

Shade Of Mine

Jester schrieb:

ja, da stimme ich vollkommen zu.

wie passt das damit zusammen das reflection nicht über ipc laufen kann? was laut dir ja der grundstein von reflection ist: da reflection ja nur reflection ist, wenn es in meinem eigenen programm stattfindet.

wenn der anstoß von extern kommen kann - kann dann nicht metainformation über einen treiber nicht auch reflection sein?

@spiegel:
deine definition geht davon aus dass ich selbst die metainformationen über mich bereitstellen muss, was zwar gängig und praktisch ist, aber imho kein zwang ist (mir ist es ja egal woher ich diese metainformationen bekomme, solange ich sie bekomme). aber ansonsten kann ich dem nur zustimmen.

Shade Of Mine schrieb:

wenn der anstoß von extern kommen kann - kann dann nicht metainformation über einen treiber nicht auch reflection sein?

Wenn es um Metainformationen ginge, hättest Du recht. Aber Du bekommst keine Metainformationen über den Treiber, wenn Du die Auflösung abfragst. Es geht nicht um die "Beschaffenheit" des Treibers. Du musst nicht zuvor per Reflection ermitteln, wie Du an das Property "Auflösung" herankommst. Du fragst doch einfach ab.

otze

ihoernchen schrieb:

Meiner Meinung nach wäre das keine reflection.
Ok, wie schon angesprochen ist das nun Haarspalterei und jeder wird es anders sehen.
Und dazu kommt ich durch java und C# vorgeschädigt

[...]
Die über reflection zugändlichen Meta-Daten sind immer vorhanden (z.B. der Compiler generiert diese). Sie sind unabhängig von der Schnittstelle eines Objekts zugänglich.

Ich denke nicht, dass die anforderungen für reflection sind, dass der compiler die daten liefert. Für reflektion ist meiner ansicht nach nur erforderlich, dass es eine Blackbox gibt, von der ich weis, dass ich sie ansprechen kann, und dass diese Blackbox daten hat die mir erklären, wie ich sie nutzen kann.

In Java geht das ja automatisch. meines wissens nach ist die reflection Schnittstelle in Object enthalten, und jede Klasse erbt automatisch davon.
genauso wie jede Klasse automatisch diese daten enthält.

In C++ gibt es das nicht, was nichts daran ändert, dass ich diese basisklassenbeziehung von hand einfügen kann, oder die daten in die Klasse von Hand mit einkompiliere.

Die Sprache ist Schlussendlich doch nur ein tool um irgendein bestimmtes verhalten zu erreichen. Mit manchen geht es besser, mit anderen schlechter, aber es geht.

Wir haben ein A und A kann Reflection wenn A weiß wie A aufgebaut ist und wenn A A modifizieren kann.

In dem Englischen Zitat steht aber nichts von modifizieren :). Reflection ist, wenn A informationen über sich selbst besitzt. In dem Fall ist es durchaus reflection, wenn es irgendwo einen server gibt, den wir fragen können, welche Protokolle er unterstützt.

Jester

otze schrieb:

In dem Englischen Zitat steht aber nichts von modifizieren :).

Stimmt, hat ja auch keiner behauptet.

Reflection ist, wenn A informationen über sich selbst besitzt.

Ganz genau. A weiß über sich selbst bescheid, und genau das ist Reflection. Ein B, das von außen irgendwas anstößt ist für die Definition von Reflection weder notwendig noch hinreichend.

Ich bin auch nicht der Meinung, dass es sich bei A unbedingt um eine Blackbox (was auch immer das hier genau heißen soll) handeln muß. Insbesondere wird ein Programm, das sich selbst modifiziert sich wohl selbst kaum als Blackbox behandeln.

ich glaube nicht, dass eure vorstellungen von reflexion so unterschiedlich sind.
shade versucht eben immer wieder, ein objekt von außen dazu zu bekommen; jester sieht reflexion als etwas, das auch ohne äußerliche einflüsse funktionieren kann.

die probleme, die shade an jester sieht, ist dass dieses innen/außen nicht so fix definiert ist und dass daher immer etwas von außen als etwas inneres angesehen werden kann (was ihn natürlich wieder direkt zu seiner eigenen definition führt). im gegensatz dazu bleibt jester bei reflexion als wissen über sich selbst, das außerdem in sich selbst vorhanden ist.

ich glaube, so ist es leicht, ein beispiel zu finden, dass jeweils für einen von euch nicht reflexion darstellt, es aber für den anderen schon sein könnte.

bleiben wir bei

int i = vec.size();

wäre dies eine information, die von außen kommt und information über ein objekt "vec" liefert, so dass das programm nun weiß, wie es vec behandeln kann (z.b. mit operator[] statt vector<int>::at), dann kann man sagen, dass vec über seine aktuelle struktur informationen bereitstellt, vec also weiß, wie es aussieht - und für shade reicht das, sofern vec als blackbox verwendet wird, über die es informationen auszulesen gilt.

für jester könnte dieses beispiel in einem anderen kontext reflexion bedeuten, so wie ich seine definition bis jetzt verstanden habe. und zwar in folgendem:

class vector
{
//...
private:
    vector_impl vec;
};

void
vector::push_back (...)
{
   int i = vec.size();
   if (i >= vec.capacity())
     vec.realloc(more);
   vec.data = ...;
}

programm (um ganz genau zu sein: vector) kennt seine eigenen struktur (nichts mit blackbox) und reflektiert i.d.S. darüber, dass es je nach aktueller struktur verschieden auf seine eigenen zustände reagiert. vector muss dafür sogar seine eigene struktur kennen, da es sich sonst nicht selbst modifizieren könnte (std::vector ist zwar generisch nach außen, aber nicht intern für sich). (ich hoffe, ich überstrapaziere jester mit diesem beispiel nicht).

ich glaube, dass shades definition von reflexion sich immer auf ein anderes objekt bezieht, das im kontext zu einem bestimmten programm steht; und [i]dieses* ist subjekt der reflexion.
jester wechselt die perspektive und sieht ein programm/objekt für sich, dass über seine eigene struktur bescheid weiß (und eventuell diese modifizieren kann); dieses ist subjekt der reflexion.
deshalb entsteht dann auch die diskussion darüber, ob man ein anderes objekt für reflexion braucht oder nicht.

in wahrheit wechseln beide nur die perspektive - um jester an shade of mine heranzubringen, müsste er sich nur vorstellen, dass sein programm/objekt x informationen über sich selbst einem anderen zur verfügung stellt, welches dann selbst intern bestimmte entscheidungen trifft (dieses andere kann natürlich auch dasselbe sein wie x selbst);
um shade of mine an jester heranzubringen, müsste er wohl erkennen, dass dieses andere objekt, die blackbox, die informationen preisgibt, diese informationen auch an sich selbst übergeben kann und für sich selbst schon reflexion anwendet, ohne ein verschiedenes "eigenes" programm/objekt zu brauchen, d.h. es kann sich selbst diese informationen geben (dann ist es keine blackbox mehr) - dann verschwindet letztendlich auch die unterscheidung zwischen was zu einem programm gehört und was nicht und der begriff blackbox.

übrig bleibt die definition, die sowieso auf der wikipedia nachzulesen ist: das kennen der eigenen struktur (und eventuell das modifizieren davon).

Nachdem ihr nicht drauf kommt (auf jedenfall nicht in dem Teil den ich gelesen hab), sag ich euch mal was das wichtige ist. Es werden Informationen aus der Programmstruktur verwendet, nicht Programmdaten. Daten die einfach nur im Programm stehen oder Variablen zugewiesen sind, wie z.B. "Dieser Treiber kann Methode X Y und Z", haben nix mit Reflection zu tun. Also nicht Informationen über die Programmstruktur die als Daten im Programm hinterlegt sind, sondern Informationen direkt aus der Programmstruktur.

Shade Of Mine

qb@work schrieb:

ich glaube, dass shades definition von reflexion sich immer auf ein anderes objekt bezieht, das im kontext zu einem bestimmten programm steht; und dieses ist subjekt der reflexion.

Jein. Es kann sich auf ein externes/anderes Objekt beziehen - muss aber nicht.

Ich trenne nicht woher die Informationen kommen - das wie und woher ist mir egal -> bei mir steht die Information selbst im Mittelpunkt.

Wenn wir zB ein Objekt haben, und ich mir irgendwie anzeigen lasse welche Methoden es anbietet und dann je nach gefallen ein paar dieser Methoden aufrufe - dann ist das fuer mich Reflection.

Unabhaengig davon was das fuer ein Objekt ist, woher ich die Daten habe, wie das technisch implementiert ist - was zaehlt:
ich habe ein Objekt - darueber bekomme ich Metainformationen und diese Metainformationen kann ich einsetzen um das Objekt zu manipulieren.

jester wechselt die perspektive und sieht ein programm/objekt für sich, dass über seine eigene struktur bescheid weiß (und eventuell diese modifizieren kann); dieses ist subjekt der reflexion.
deshalb entsteht dann auch die diskussion darüber, ob man ein anderes objekt für reflexion braucht oder nicht.

Soweit ich die Diskussion verstanden habe geht es darum ob es andere objekte geben darf oder nicht.

um shade of mine an jester heranzubringen, müsste er wohl erkennen, dass dieses andere objekt, die blackbox, die informationen preisgibt, diese informationen auch an sich selbst übergeben kann und für sich selbst schon reflexion anwendet, ohne ein verschiedenes "eigenes" programm/objekt zu brauchen, d.h. es kann sich selbst diese informationen geben (dann ist es keine blackbox mehr) - dann verschwindet letztendlich auch die unterscheidung zwischen was zu einem programm gehört und was nicht und der begriff blackbox.

Was du schreibst widerspricht sich mit mir nicht. Da mir egal ist woher die Metainformation kommt, kann sie durchaus auch (und das ist wohl das gaengige Verhalten) von dem Objekt selbst kommen. Sie kann aber auch von der Runtime kommen.

Vielleicht ist wirklich das Wort "Blackbox" das Problem. Was ich damit ausdruecken will: ein Objekt ueber das ich Metainformationen wissen will. uU bin ich selbst dieses Objekt.

Die Frage ist: woher kommen diese Metainformationen ueber das Objekt. uU weiss das Objekt diese Sachen selber - in Java gibt es zB ein eigenes Objekt dass die Metainformationen ueber ein anderes Objekt besitzt. Wir nennen es class-Objekte. In den meisten Interpreter Sprachen kennt die Runtime diese Informationen - sie speichert sie irgendwo. Manchmal direkt im Objekt selber - manchmal irgendwo extern. Aber mir ist das alles egal: was zaehlt ist dass ich diese Metainformation abrufen kann.

Reflection in C++ ist zB statisch und ein Typ weiss selber nicht ob er jetzt const ist, volatile oder ein Zeiger. Ich kann aber Methoden verwenden um diese Daten zu ermitteln (naehmlich partielle template spezialisierung). Was fuer mich zaehlt ist: ich kann fragen: bist du (oder auch ich) const? Und bekomme als Antwort ja oder nein. Ob ich jetzt
type::is_const
oder
type_traits<type>::is_const
schreibe ist mir dabei egal und gehoert IMHO zur Implementierung der Reflection und nicht zu seiner Definition.

@Mocks:
Ich rede deshalb von Metainformationen. Ob eine Liste der Aufloesungen jetzt Metainformation ist oder nicht, ist IMHO eine andere Diskussion. Was zB Metainformation waere (in meinen Augen) eine Liste der unterstuetzten OpenGL Funktionen.

Jester

Shade Of Mine schrieb:

Soweit ich die Diskussion verstanden habe geht es darum ob es andere objekte geben darf oder nicht.

ne, mir geht es darum ob es sie geben *muss*. und ich finde es muss nicht. dürfen tut's das wohl.

ob man die information nun auch von irgendwo außerhalb kommen darf ist eine andere frage.

TheTester

[quote="Jester"]

Shade Of Mine schrieb:

Soweit ich die Diskussion verstanden habe geht es darum ob es andere objekte geben darf oder nicht.

ne, mir geht es darum ob es sie geben *muss*. und ich finde es muss nicht. dürfen tut's das wohl.

[...]quote]

Und an "wen" gehen die Informationen wenn du eine Komponente darum bittest dir Auskunft über sich selbst zu geben? Es kann natürlich auch sein das die Komponente sich selbst modifiziert und dann eine "Selbst-"Reflexion durchführt um auf die geänderte Struktur einzugehen. Aber was denn nun?

Irgendwie hab ich grad den Faden verloren ^^ kann man jmd die gegensätzlichen Meinungen kurz gegenüberstellen?

Shade Of Mine

Jester schrieb:

Shade Of Mine schrieb:

Soweit ich die Diskussion verstanden habe geht es darum ob es andere objekte geben darf oder nicht.

ne, mir geht es darum ob es sie geben *muss*. und ich finde es muss nicht. dürfen tut's das wohl.

ob man die information nun auch von irgendwo außerhalb kommen darf ist eine andere frage.

muss nicht. ne. es muss sie nur geben dürfen.

dann ist also die frage ob information von aussen kommen darf? bestes beispiel java: class objekte beschreiben klassen und class objekte sind extern von der runtime zur verfügung gestellt. die objekte selbst kennen ihre struktur nicht - dazu braucht man externe class objekte.

ergo: die information kann (muss aber nicht) von externen resourcen bereitgestellt werden dürfen (natürlich auch von internen objekten oder dem objekt selber).

Shade Of Mine schrieb:

Ich trenne nicht woher die Informationen kommen - das wie und woher ist mir egal -> bei mir steht die Information selbst im Mittelpunkt.

Du vielleicht nicht, aber genau darum gehts bei Reflection. Wenn du dir eine Javaklasse schreibst und eine getMethodNames() Methode einbaust und dort nur als Daten eingetragene Strings zurück gibst, dann ist das halt kein Reflection. Da wird keiner sagen das ist Reflection, sondern nur fragen, warum du das nicht per Reflection machst. Wenn du Reflection verwendest, werden diese Informationen nämlich aus der Programmstruktur geholt und nicht aus den Programmdaten. Bei Reflection geht es nicht darum welche Daten zurückgegeben werden und was du damit machst (z.B. vorhandene Methoden aufrufen), sondern darum das mit Informationen aus der Programmstruktur (!= Programmdaten) gearbeitet wird.

Shade Of Mine

FachmannFürReflection schrieb:

Shade Of Mine schrieb:

Ich trenne nicht woher die Informationen kommen - das wie und woher ist mir egal -> bei mir steht die Information selbst im Mittelpunkt.

Du vielleicht nicht, aber genau darum gehts bei Reflection. Wenn du dir eine Javaklasse schreibst und eine getMethodNames() Methode einbaust und dort nur als Daten eingetragene Strings zurück gibst, dann ist das halt kein Reflection. Da wird keiner sagen das ist Reflection, sondern nur fragen, warum du das nicht per Reflection machst. Wenn du Reflection verwendest, werden diese Informationen nämlich aus der Programmstruktur geholt und nicht aus den Programmdaten. Bei Reflection geht es nicht darum welche Daten zurückgegeben werden und was du damit machst (z.B. vorhandene Methoden aufrufen), sondern darum das mit Informationen aus der Programmstruktur (!= Programmdaten) gearbeitet wird.

Sprich Reflection in C++ ist unmoeglich?
Wie erklaerst du dir dann Reflection Libraries fuer C++ oder die statische Reflection ueber zB type_traits?

Das Problem hierbei ist, dass du denkst alles was die Runtime macht ist Magie. Wenn ich genau das selbe mache wie die Java Runtime nur eben nicht in der Runtime sondern einer externen Library - wieso ist es dann nicht Reflection? Die Java Runtime zaubert nicht, sie kennt nur Informationen die man normalerweise nicht kennt - sie kommt an diese Informationen aber nur weil der Compiler ihr eine Liste der Methoden gibt die eine Klasse unterstuetzt. Wenn dieser Prozess nicht direkt beim Kompilieren sondern in 2 Schritten erfolgt - dann ist das in meinen Augen ein Implementationsdetail.

Ich will ein Objekt foo haben und sagen koennen: irgendwer liefere mir bitte eine Liste aller unterstuetzten Methoden so dass ich alle aufrufen kann die ein a im Namen haben.

Wenn ich soetwas machen kann, warum ist es dann wichtig ob die Java Runtime diese Information vom Compiler bekommen hat oder ob die C++ Library diese Information von einem pre-compiler bekommen hat oder ob es einfach ein allwissendes Gott-Objekt ist, dass einfach alles weiss.

Bei Java ist es zB so, dass das Objekt selber keine Informationen ueber die eigene Struktur hat. Es gibt dafuer externe Objekte die beim kompilieren automatisch miterstellt werden: naemlich die class-objekte. Diese haben Informationen ueber die einzelnen Klasse. Zufaelligerweise ist das technisch direkt in die Java Runtime eingebaut. Da aber diese Informationen ja im .class File stehen (weil sie der Compiler dort hinein schreibt) koennte man, wenn es diese Class Objekte in der Runtime nicht gaebe, sie selber schreiben.

Waere es Reflection wenn ich die Java Reflection als externe Library einbinden muesste bzw. selber schreiben muesste?

Shade Of Mine schrieb:

Wie erklaerst du dir dann Reflection Libraries fuer C++ oder die statische Reflection ueber zB type_traits?

statisch reflection gibt es nicht. reflection ist immer dynamisch. es bedeutet, daß ein program zur laufzeit seine eigene struktur kennt und sich selbst, wenn es nötig sein sollte, verändern kann. ein c-programm müsste z.b. seinen eigenen maschinencode analysieren, etwa mit hilfe hineincompilierter debug-infos.
so ähnlich stehts auch im englischsprachigen wikipedia-artikel.

In C++ kannst du nur sehr begrenzt reflection durchführen, weil hast fast keine nutzbaren Informationen über die Programmstruktur vorhanden sind, genauso wie bei C. Klar kannst du irgendwelche Frameworks oder Compiler verwenden die alle möglichen zusätzlichen Information ins Programm reinstecken und damit dann Reflection durchfürhen. Mit externen Libraries die diese Informationen nicht haben, können diese Frameworks aber schon nicht mehr viel anfangen.

Das Problem an deiner Definition ist einfach, dass du einen Anwendungsfall von Reflection zur Definition machst und dann meinst, alles mit dem du diesen Anwendungsfall nachbauen kannst ist Reflection. Das du mit Informationen über die Programmstruktur die du irgendwo her bekommen hast etwas machst ist aber nicht Reflection. Reflection ist diese Informationen aus der Programmstruktur zu holen und die Programmstruktur zu ändern (Für alle Schlaumeier: Das ist kein logisches UND).

Bei Java ist es zB so, dass das Objekt selber keine Informationen ueber die eigene Struktur hat. Es gibt dafuer externe Objekte die beim kompilieren automatisch miterstellt werden: naemlich die class-objekte. Diese haben Informationen ueber die einzelnen Klasse.

Objekte kennen ihre class-Objekte, also kennen Objekte auch ihre Struktur! Wieso zum Teufel sollte man da unterscheiden? Soll jedes einzelne Objekt eine Liste mit seinen Methodennamen mit rumschleppen? Hohe Kapselung und geringe Kopplung sind grundlegende Primzipien der Objektorientierten Programmierung!

Shade Of Mine

fricky schrieb:

statisch reflection gibt es nicht. reflection ist immer dynamisch. es bedeutet, daß ein program zur laufzeit seine eigene struktur kennt und sich selbst, wenn es nötig sein sollte, verändern kann. ein c-programm müsste z.b. seinen eigenen maschinencode analysieren, etwa mit hilfe hineincompilierter debug-infos.
so ähnlich stehts auch im englischsprachigen wikipedia-artikel.

statische Reflection wie zB type_traits. Siehe Wikipedia

FachmannFürReflection schrieb:

In C++ kannst du nur sehr begrenzt reflection durchführen

Also ist es nur Reflection wenn es mehr als 50% der Reflection features von Java anbietet? Oder 48%? Oder braucht man absolute mehrheit mit >75%?

ein bisschen schwanger sein ist eine interessante definition

ogottogott schrieb:

Objekte kennen ihre class-Objekte

Wenn also die Objekte die class objekte nicht kennen, weil man zB nicht alles von einer basis klasse ableitet ist es keine reflection mehr?