Reflection
-
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?
-
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.
-
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.
-
In C++ gibt es sehr wohl Reflection: google c++ reflection
-
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.
-
Moin,
bei so viel interesse an diesem Thema, wäre das nicht ein Magazin Artikel wert?MFG
-
Was soll es bringen, wenn 50% in akzeptieren und 50% nicht, je nachdem wer ihn geschrieben hat?
-
Hoffmann schrieb:
Moin,
bei so viel interesse an diesem Thema, wäre das nicht ein Magazin Artikel wert?eigentlich nicht. man findet schon viel dazu im internet, z.b. das: http://www.petendi.de/seminare/reflection/parts/reflection_petendi_hausarbeit.pdf
-
fricky schrieb:
das ist keine reflection
Wenn ich einen C++ Interpreter nehme wird es zur Laufzeit ausgefuehrt. Wenn ich dann Typen dynamisch lade, sind die Typen zur Compilezeit sowieso nicht bekannt.
Genau das selbe mit statischer Polymorphie. Langweilige Diskussion - denn eine Trennung Runtime/Compiletime ist heutzutage nicht mehr machbar.
und bedenke: ich kann in Java auch Reflection auf nur bekannte Objekte machen - Reflection so zu definieren dass es nur auf Objekte geht die zur Zeit des Codeschreibens unbekannt waren, ist etwas gewagt. Weil somit viele Programme die die Java Reflection API verwenden ploetzlich nicht mehr in die Reflection Definition reinfallen.
Bei type_traits habe ich Typen (wenn man so will: objekte) und ich kenne einige Metainformationen nicht. Deshalb verwende ich type_traits um an diese Metainformationen zu kommen: zB, ist dieser Typ const, ist er eine Referenz - und dann manipuliere ich ihn so, dass er mir passt: ich nehme ihm das volatile und den Zeiger und mache ihn zu einer const Referenz.
Ihr seht jetzt nur: aber das passiert bei der Compiletime - aber wenn wir einen C++ Interpreter nehmen, passiert es waehrend der Laufzeit
Diese Trennung Compile/Runtime ist einfach nur veraltet.Den Einwand von Gregor find ich super
Irgendwie finde ich es sehr schade dass die Java Definition eines Konzeptes immer die allgemeingueltige Definition sein muss. Reflection die weniger Moeglichkeiten bietet als die Java Reflection ist automatisch keine Reflection mehr - aber wenn ich eine Sprache habe die mehr Reflection Moeglichkeiten bietet als Java es tut, so ist das egal.
-
Shade Of Mine schrieb:
und bedenke: ich kann in Java auch Reflection auf nur bekannte Objekte machen - Reflection so zu definieren dass es nur auf Objekte geht die zur Zeit des Codeschreibens unbekannt waren, ist etwas gewagt. Weil somit viele Programme die die Java Reflection API verwenden ploetzlich nicht mehr in die Reflection Definition reinfallen.
Was sollen den bei dir unbekannte Objekte sein? Auf jedes Objekt das es im Programm gibt kann ich Reflection anwenden, egal ob ich das schon beim schreiben des Programms kenne oder ob ich später eine weitere Jar Datei beim Classpath meines Programms angebe und das Objekt daraus kommt. Oder was ist bei dir ein unbekanntes Objekt?Den Einwand von Gregor find ich super
Irgendwie finde ich es sehr schade dass die Java Definition eines Konzeptes immer die allgemeingueltige Definition sein muss. Reflection die weniger Moeglichkeiten bietet als die Java Reflection ist automatisch keine Reflection mehr - aber wenn ich eine Sprache habe die mehr Reflection Moeglichkeiten bietet als Java es tut, so ist das egal.Wo hat hier jemand behauptet, dass das was in Java geht die Definition für Reflection ist?
-
Shade Of Mine schrieb:
Wenn ich einen C++ Interpreter nehme wird es zur Laufzeit ausgefuehrt. Wenn ich dann Typen dynamisch lade, sind die Typen zur Compilezeit sowieso nicht bekannt.
Genau das selbe mit statischer Polymorphie. Langweilige Diskussion - denn eine Trennung Runtime/Compiletime ist heutzutage nicht mehr machbar.
Mit dir zu diskutieren ist sinnlos. Du hast dir eine ganz Menge eigener Definitionen zurecht gelegt, die nicht den allgemeinen Definitionen entsprechen, aber du hältst sie für allgemeiner, besser und moderner und jeder der dem nicht zustimmt, der versteht es einfach nicht und denkt nicht so "fortschrittlich" und "weitblickend" wie du.
Natürlich ist die Laufzeit, Compilezeit und Interpretationszeit was anderes, auch wenn es mit JIT-Compiler und Multicoresystemen praktisch parallel ablaufen kann.
-
erdtfghj schrieb:
Oder was ist bei dir ein unbekanntes Objekt?
Siehe frickys Post.
FachmannFürReflection schrieb:
Mit dir zu diskutieren ist sinnlos. Du hast dir eine ganz Menge eigener Definitionen zurecht gelegt, die nicht den allgemeinen Definitionen entsprechen, aber du hältst sie für allgemeiner, besser und moderner und jeder der dem nicht zustimmt, der versteht es einfach nicht und denkt nicht so "fortschrittlich" und "weitblickend" wie du.
Mit dem Unterschied dass ich sie mir nicht selber ausgedacht habe, sondern von Stroustrup, Meyers, Sutter, Coplien, Stroustrup, Meyer, Armstrong und wie sie alle heissen uebernommen habe. Das Problem ist nur, diese Leute schreiben keine Buecher die jeder liest. Die Standard Java Definition von einem Konzept kann ich in jedem Anfaenger Java Buch nachlesen - und das ist auch gut. Wenn ich nur Sprache X Programmiere muss ich nur die Konzepte kennen wie sie dort vorkommen. Das Problem an Diskussionen wie diesen hier ist, dass Leute die dann nur Sprache X kennen die Definition des Konzeptes von X uebernehmen und sagen: das ist das Konzept.
Aber andere Sprachen gehen komplett anders an die Sache heran - das Konzept bleibt aber gleich, was sich aendert sind die techniken und vielleicht die Blickwinkel. Man nehme zB Objekt Orientierte Programmierung. Manche Leute sagen man braucht Klassen dafuer. Andere sagen man braucht Information Hiding, andere sagen man braucht Laufzeitpolymorphie. Was es aber wirklich ist, ist ein Konzept dass durch verschiedene techniken unterstuetzt wird. zB sind Klassen einfach praktisch weil man dadurch Vererbung hat. Aber in Prototype Sprachen hat man halt keine Klassen, dafuer Prototypen die man manipulieren kann. Das ist auch etwas unheimlich praktisches. Es sind eben 2 Auspraegungen von dem gleichen Konzept.
Und genau so ist es mit fast allen Konzepten die wir zum Programmieren verwenden. Reflection in C++ laeuft eben ueber type_traits. In JavaScript ueber Prototypes und in Java habe ich ein Class Objekt. Technisch sind diese 3 Auspraegungen enorm Unterschiedlich.
zB koennte man argumentieren dass Java keine echte Reflection bietet, weil die Prototypen aus JavaScript einfach viel flexibler und mehr bieten als die class Objekte in Java. Und natuerlich bieten die class Objekte in Java mehr Moeglichkeiten als die type_traits aus C++. Dafuer kann man in C++ eben die Typen selber veraendern - waehrend man in Java die class Objekte nicht aendern kann.
Keins ist jetzt besser oder definitiv die einzig gueltige Variante von Reflection - alles sind Auspraegungen des Wunsches Metainformationen zu bekommen und diese Manipulieren zu koennen. Jede Sprache setzt dies eben so gut um wie es innerhalb der Sprache Sinn macht.
und es ist gut, dass die Sprachen unterschiedliche Ansaetze suchen. Die Wuensche von den Programmierern sind sich ziemlich aehnlich - aber man kann nicht alle Wuensche erfuellen. Deshalb muss es Sprachen geben die Ansaetze waehlen die eben diese Wuensche in den Vordergrund setzen und andere die andere als wichtiger Erachten. Und durch diese Verschiebung der Prioritaeten entstehen neue Blickwinkel - neue Blickwinkel auf bestehende Konzepte oder sagen wir vielleicht lieber Ideen dazu. Die Idee dass ich Metainformationen bekommen und manipulieren kann ist ueberall vorhanden. Die Auspraegung dagegen ist enorm unterschiedlich - zB ist in Sprachen mit dynamischen Typen eine manipulation der Struktur eines Objektes viel einfacher als in einer Sprache mit einem statischen Typsystem. Aber ist Reflection deshalb nur Reflection wenn ich ein dynamisches Typsystem habe?
Natürlich ist die Laufzeit, Compilezeit und Interpretationszeit was anderes, auch wenn es mit JIT-Compiler und Multicoresystemen praktisch parallel ablaufen kann.
Man kann es mittlerweile nicht mehr streng trennen. Man kompiliert teilweise nach der Laufzeit. Man Interpretiert vor der Laufzeit und nicht waehrend - insofern ist eine Trennung einfach nicht mehr vernuenftig moeglich.
-
Shade Of Mine schrieb:
Dafuer kann man in C++ eben die Typen selber veraendern - waehrend man in Java die class Objekte nicht aendern kann.
Ich weiß jetzt nicht genau, was Du meinst, aber hast Du schonmal etwas von der Instrumentation-API von Java gehört?
-
---
-
Gregor schrieb:
Ich weiß jetzt nicht genau, was Du meinst, aber hast Du schonmal etwas von der Instrumentation-API von Java gehört?
Nope. Die kannte ich nicht.
Aber wuerdest du behaupten Java kann Reflection erst seit Version 5 weil da die Instrumentation API dazu kam?
-
Shade Of Mine schrieb:
erdtfghj schrieb:
Oder was ist bei dir ein unbekanntes Objekt?
Siehe frickys Post.
FachmannFürReflection schrieb:
Mit dir zu diskutieren ist sinnlos. Du hast dir eine ganz Menge eigener Definitionen zurecht gelegt, die nicht den allgemeinen Definitionen entsprechen, aber du hältst sie für allgemeiner, besser und moderner und jeder der dem nicht zustimmt, der versteht es einfach nicht und denkt nicht so "fortschrittlich" und "weitblickend" wie du.
Mit dem Unterschied dass ich sie mir nicht selber ausgedacht habe, sondern von Stroustrup, Meyers, Sutter, Coplien, Stroustrup, Meyer, Armstrong und wie sie alle heissen uebernommen habe. Das Problem ist nur, diese Leute schreiben keine Buecher die jeder liest. Die Standard Java Definition von einem Konzept kann ich in jedem Anfaenger Java Buch nachlesen - und das ist auch gut. Wenn ich nur Sprache X Programmiere muss ich nur die Konzepte kennen wie sie dort vorkommen. Das Problem an Diskussionen wie diesen hier ist, dass Leute die dann nur Sprache X kennen die Definition des Konzeptes von X uebernehmen und sagen: das ist das Konzept.
Dann zitier doch mal die Definition von Reflection die dem entspricht was du sagst.
Natürlich ist die Laufzeit, Compilezeit und Interpretationszeit was anderes, auch wenn es mit JIT-Compiler und Multicoresystemen praktisch parallel ablaufen kann.
Man kann es mittlerweile nicht mehr streng trennen. Man kompiliert teilweise nach der Laufzeit. Man Interpretiert vor der Laufzeit und nicht waehrend - insofern ist eine Trennung einfach nicht mehr vernuenftig moeglich.
Wenn kompiliert wird ist Compiletime. Wenn das Programm was macht ist es Runtime. Wenn ein Compiler was kompiliert dann ist das die Laufzeit des Compilers und die Compiletime des Programms das kompiliert wird. Das sind immer zwei unterschiedliche Dinge, egal wann sie passieren und wie vermischt sie sind.
-
Shade Of Mine schrieb:
Gregor schrieb:
Ich weiß jetzt nicht genau, was Du meinst, aber hast Du schonmal etwas von der Instrumentation-API von Java gehört?
Nope. Die kannte ich nicht.
Aber wuerdest du behaupten Java kann Reflection erst seit Version 5 weil da die Instrumentation API dazu kam?Nein. Das Ändern von Dingen ist ja auch etwas völlig anderes als die Analyse. Ich sehe bei Reflection eigentlich nur die Analyse.
-
[quote="FachmannFürReflection"]Dann zitier doch mal die Definition von Reflection die dem entspricht was du sagst.[quote]
Genau das ist der Punkt.
Ich will Reflection nicht genau definieren. Genausowenig wie man OOP genau definieren kann. Es ist eine Idee, ein Konzept. Man versucht neue Auspraegungen davon zu finden, neue Ideen einzubauen aber man sollte nicht versuchen es sinnlos zu beschneiden.Bring mir eine Definition von Reflection und wenn sie zu genau ist, finde ich dir eine Sprache wo man Reflection gegen diese Definition implementiert hat. Oder aber die Definition ist allgemeingueltig genug, dass sie eben alle Auspraegungen (vorallem auch die die wir noch nicht kennen) anerkennt.
Wenn du Reflection definieren willst, dadurch dass ein Objekt seine eigenen metainformationen kennt, fliegt Java zB schon raus. Da ein Objekt in Java seine Metainformationen nicht kennt. Dafuer gibt es class Objekte die diese kennen und dass objekte getClass anbieten ist nur syntax zucker, denn das macht ja nichts anderes als ein Class.getClassForObject(this) oder so aehnlich.
Wenn du Reflection durch die manipulierung der Programm Struktur zur Laufzeit definierst, ist es bei Java auch schon fraglich inwiefern ein Methoden Aufruf eine Manipulation ist. Wenn eine Methodenaufruf eine Manipulation zur Laufzeit ist - dann fallen ja auch C++ Reflection Libraries rein und ploetzlich bieten Reflection Libraries auch noch statische Reflection an. Sind es also halbe-Reflection Libraries?
Das kann man mit jeder Definition so ausargumentieren.
-
Gregor schrieb:
Nein. Das Ändern von Dingen ist ja auch etwas völlig anderes als die Analyse. Ich sehe bei Reflection eigentlich nur die Analyse.
Was ein interessanter Punkt ist, da zB in der JavaScript Welt analyse und manipulation kaum voneinander Trennbar sind.
Und wieder ein wunderschoener Beweis, dass es unterschiedliche Blickwinkel gibt und dass das eben gut ist
In Java ist Reflection naemlich in der Tat 90% Informationen zu bekommen. In JavaScript ist es fast ausschliesslich Informationen zu Manipulieren - in C++ mit type_traits ist es etwa 50/50.
-
Shade Of Mine schrieb:
FachmannFürReflection schrieb:
Dann zitier doch mal die Definition von Reflection die dem entspricht was du sagst.
Genau das ist der Punkt.
Ich will Reflection nicht genau definieren. Genausowenig wie man OOP genau definieren kann. Es ist eine Idee, ein Konzept. Man versucht neue Auspraegungen davon zu finden, neue Ideen einzubauen aber man sollte nicht versuchen es sinnlos zu beschneiden.Die Idee hinter Reflection ist, dass das ein Programm Informationen aus (und nicht nur einfach über) die Programmstruktur holt und die Programmstruktur ändern kann.
Die Information über einen Methodennamen wird nicht aus einem String geholt, dem der Programmierer irgendwie einen Wert zugewiesen hat sondern stammt direkt aus der Programmstruktur. Wie das gemacht wird ist völlig egal. Wenn dein Programm auf einem System läuft, dass den Aufbau aller Klassen in einer Datenbank hält, dann kannst du im Programm das System nach der Information fragen und es wird dir den Namen aus der Datenbank geben. Das wichtige ist einfach nur, dass der Name nicht vom Programmierer irgendwo als Programmdaten hinterlegt wird, sondern direkt aus der Programmstruktur ist.
Beim ändern der Programmstruktur ist es ähnlich. In ABAP ist z.B. Reflection teilweise in die Syntax eingebaut und da sieht man sehr gut was die Idee hinter dem Ändern der Programmstruktur ist. Du kannst einem Element einer Struktur z.B. direkt einen Wert zuweisen oder per Reflection.
Ich weiß die Syntax nicht mehr genau, aber ungefähr so war es.
direktstruct-element = 'abc'.Reflection
struct-(elementNameAlsString) = 'abc'.Wenn du jetzt in einer Schleife den Wert von elementNameAlsString änderst, dann ändert sich immer die Programmstruktur an der Stelle "struct-(elementNameAlsString) = 'abc'.". Ob da intern jetzt immer neu kompiliert oder nur die Adresse des Elements irgendwo gesetzt wird, weiß ich nicht. Es geht einfach um die Idee das hier zumindest theoretisch die Programmstruktur verändert wird und nicht, dass ein Programmierer eine einfache Adresszuweisung in sein Programm schreibt.