[nem-pl] Propozycja zmian w API kompilatora

Kamil Skalski nazgul at omega.pl
Wed May 19 11:13:46 CEST 2004


Troszkę przeglądałem System Reflection i strukturę naszych klas i proponuję 
coś takiego

NemerleMember -> MemberInfo  , NemerleField -> FieldInfo, etc.
Tycon -> IType
Tyinfo -> TypeInfo  
wyuskać z Tyinfo funkcjonalność do zmiany danego typu i zrobić TypeBuilder

co prawda NemerleMember i NetMember   implementujące IMember, to całkiem fajna 
konstrukcja, ale może dla przybliżenia nazwenictwa z S.R
NetMemberInfo i MemberInfo zrobić?

W Longhorn jest takie coś jak IReflect, które jest zdaje się implementowane 
tylko przez S.Type więc nie wiem po co jest i można go chyba umieścić w IType

Zasadniczo FieldInfo odpowiada S.R.FieldInfo, ale np.TypeInfo odpowiada 
System.Type  (oni mają niespójnie, ale to chyba z powodu takiego, że S.Type 
jest często używany i woleli krótką nazwę)

Chciałbym usłuszeć jakiś argument, dlaczego Typedtree.Type różni się 
czymkolwiek od TypeInfo - wiem, że tam są np. array<int> ale w sumie 
array<int> też chyba ma swojego TypeInfo (no w .NET def x = array<int> 
x.GetType COŚ zwraca).

A może udałoby się ładniej uniknąć dualizmu Net / Nemerle  Field? Np. jedno 
dziedziczyłoby po drugim? W sumie NemerleField jest bogaszy (a w każdym razie 
TypeInfo), bo zawiera informacje o kodzie źródłowym.




More information about the devel-pl mailing list