Reflection

[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.

[qb@work]

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).

[FachmannFürReflection]

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).

[FachmannFürReflection]

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?

[fricky]

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.

[FachmannFürReflection]

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).

[ogottogott]

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?

[FachmannFürReflection]

Shade Of Mine schrieb:

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

Sehr schlau. Was besseres als vollkommen zusammenhangloses zitieren um dann mit Schwachsinn darauf antworten zu könne ist dir wohl nicht mehr eingefallen.

[Gregor]

FachmannFürReflection schrieb:

Shade Of Mine schrieb:

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

Sehr schlau. Was besseres als vollkommen zusammenhangloses zitieren um dann mit Schwachsinn darauf antworten zu könne ist dir wohl nicht mehr eingefallen.

Man muss allerdings sagen, dass es in Java auch Dinge gibt, die man leider nicht via Reflection herausfinden kann. Das betrifft zum Beispiel die Namen von Methodenparametern. Oder einige Dinge im Zusammenhang mit Generics. Die sind ja leider mittels Erasure implementiert.

[Kenner des C++]

In C++ gibt es sehr wohl Reflection: google c++ reflection

[fricky]

Shade Of Mine schrieb:

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

das ist keine reflection, auch wenn wikipedia das anders sieht. es geht nun mal nicht nur darum, metainformationen abzufragen und mit template-tricks den compiler dazu zu bewegen, speziellen code zu erzeugen. es geht ausschliesslich um laufzeitdynamik wie z.b. neue objekte und arrays zu erzeugen, von denen zur compilezeit nicht das geringste bekannt ist, kein name, kein typ usw. und diese objekte dann zu benutzen, als wären sie schon beim compilieren existent. die einzigen möglichkeiten die ich für c++ und c sehe, sowas zu machen sind:
1. das programm analysiert seinen maschinencode kann ihn verändern.
2. das programm ändert seinen quelltext und compiliert sich dann selbst.

[Hoffmann]

Moin,
bei so viel interesse an diesem Thema, wäre das nicht ein Magazin Artikel wert?

MFG

[witte]

Was soll es bringen, wenn 50% in akzeptieren und 50% nicht, je nachdem wer ihn geschrieben hat?