2008-12-19 9 views
0

J'ai actuellement un problème dans mon implémentation de langage DLR où les appels suivants à une méthode définie dans le langage se produisent avec les mêmes paramètres d'entrée utilisés par le premier appel à cette méthode.Objet du paramètre Restrictions dans le constructeur MetaObject?

Alors ... si je le fais dans ma langue:

PrintType(34); 
PrintType(34.1); 

... la sortie est:

Entier

Entier

Là où je attendreait:

Entier

décimal

Je pense (mais ne peut pas encore confirmer) que les résultats d'émission de ce qui suit:

  1. mon classeur d'appel (sous-classe invokeAction) génère un appel approprié Expression, puis renvoie un nouveau MetaObject avec cette expression et Restrictions.Empty

  2. t Par conséquent, je pense que ce qui pourrait arriver est que le paramètre Restrictions informe le DLR quand cette construction peut être réutilisée pour des appels ultérieurs à cette méthode, et comme je ne place aucune restriction inhérente, la première construction est toujours réutilisée (désolé, ma terminologie ici est sans doute pas ... nous espérons que vous avez l'idée)

Alors ... Je pense que je dois utiliser une fusion des restrictions générées pour chaque paramètre par type ... , ou peut-être par exemple.

Est-ce que quelqu'un peut confirmer ou infirmer ma pensée? D'autres possibilités que je devrais explorer, pour le comportement que je vois?

TIA ...

Répondre

1

Votre opinion est correcte. Dans ce cas, vous aurez besoin d'une restriction de type - en général, vous voulez avoir le moins de restrictions possible afin que le code puisse être partagé depuis autant de sites d'appel que possible. La façon dont cela fonctionne est qu'avant de demander une règle à votre relieur, le DLR recherche une règle mise en cache. Les restrictions sont ce qui empêcherait la règle en cache d'être applicable à un nouvel ensemble d'entrées.

+0

Merci beaucoup (encore une fois) Dino ... qui l'a eu. Le DLR commence lentement à avoir du sens. :-) – JoshL