Ich habe eine dynamische Typisierungsbibliothek für D implementiert, als ich auf ein interessantes Problem stieß.
Im Moment ist es mir gelungen, eine Funktion namens dynamic() zu erstellen, die eine dynamische Version eines Objekts zurückgibt.
Zum Beispiel:
%Vor% Das Problem, auf das ich gestoßen bin, ist die Tatsache, dass writeln versucht, Zeit für die Kompilierung zu verwenden, um herauszufinden, wie result behandelt werden soll.
Was ist das erste, was es versucht? isInputRange!(typeof(result))
Das Problem ist, es gibt true zurück! Warum? Weil ich davon ausgehen muss, dass alle Mitglieder, die es braucht, existieren, es sei denn, ich kann zur Laufzeit etwas anderes nachweisen - was zu spät ist. Also versucht das Programm front , popFront und empty auf result aufzurufen, was mein Programm zum Absturz bringt.
Ich kann mir keinen Weg vorstellen, das zu beheben. Hat jemand eine Idee?
Sie versuchen, zwei grundsätzlich unterschiedliche Konzepte zusammenzuarbeiten, nämlich Templates und dynamische Typisierung. Vorlagen beruhen sehr auf statischer Typisierung, isInputRange funktioniert, indem überprüft wird, welche Attribute oder Methoden ein Typ hat. Ihr dynamischer Typ wird bei der Kompilierung so behandelt, als hätte er jedes Attribut oder jede Methode. Daher wird er so behandelt, als würde er alle statischen Duck-Typing-Interfaces erfüllen. Damit Dynamic in einer statisch typisierten Umgebung funktioniert, müssen Sie an einigen Stellen mehr statische Informationen bereitstellen.
Einige Lösungen, die ich sehen kann:
stellt Ihre eigenen dynamisch typisierten Implementierungen für häufig verwendete Funktionen bereit. Das ganze Problem, das Sie haben, wird durch die Tatsache verursacht, dass Sie versuchen, generische Funktionen zu verwenden, die eine statische Typisierung mit dynamischen Typen voraussetzen.
macht dynamisch einen Bereich von char und kümmert sich selbst um die Umwandlung in die Zeichenkette der zugrunde liegenden Daten. (Sie müßten sowieso eine benutzerdefinierte toString-Methode haben, wenn das isInputRange-Problem nicht vorhanden wäre, da andernfalls das Ergebnis wieder vom dynamischen Typ wäre). Dies würde wahrscheinlich schreiben (d); arbeiten.
stellt Wrapper für dynamic bereit, mit denen Sie dynamische Typen in verschiedene Vorlagenfunktionen übergeben können. (Diese würden nur eine statische Schnittstelle aufweisen und alle Aufrufe an Dynamic weiterleiten).
ZB:
%Vor%4. Fügen Sie Dynamic eine Elementvorlage hinzu, mit der Sie einige Elementfunktionsnamen statisch deaktivieren können.
ZB:
%Vor% Was ist falsch daran, std.variant zu verwenden, das alles implementiert, was Sie für dynamisches Tippen benötigen ( zusammen mit ziemlich viel syntaktischem Zucker)
Könnten Sie eine Überladung für isInputRange bereitstellen? So etwas (beachte, dass ich die Implementierung von isInputRange nicht betrachtet habe):
%Vor%Wenn dies von Ihrem dynamic.core bereitgestellt wird, denke ich, dass diese Überladung vor der Standardbibliothek ausgewählt werden sollte.
Für den allgemeinen Fall muss Dynamic jede Methode zur Kompilierungszeit akzeptieren, wie Sie gesagt haben. Nehmen wir einmal an, Sie könnten verhindern, dass das Prädikat "isInputRange" auf "true" auswertet, jetzt wird beim Versuch, aus einem Eingabebereich ein Dynamic zu erstellen, der falsche Code generiert.
Ich denke nicht, dass das reparierbar ist, zumindest nicht allgemein. In diesem speziellen Fall ist die beste Lösung, die ich mir vorstellen kann, dass Dynamic seine eigene Version von toString bereitstellt, und writeln würde dies gegenüber der inputRange-Spezialisierung bevorzugen. Ich glaube, writeln macht das momentan nicht, zumindest nicht für Strukturen, aber das sollte es wahrscheinlich tun.
Ein weiterer Kompromiss wäre, einige Methoden wie popFront in der opDispatch-Einschränkung zu verbieten, stattdessen würde dynamic opIndex oder ein Member-Objekt für den Zugriff auf diese speziellen Fälle bereitstellen. Dies ist möglicherweise nicht so schlimm wie es klingt, weil die speziellen Fälle selten sind und deren Verwendung zu einem offensichtlichen Compilerfehler führen würde.
Ich denke, dass der beste Weg, diese Art der Methodenauflösung für Dynamic zu retten, darin besteht, writeln zu korrigieren und zu akzeptieren, dass Dynamic nicht mit dem gesamten Vorlagencode funktioniert.
Tags und Links d dynamic-typing d2