[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