[nem-pl] Propozycja zmian w API kompilatora

[Michal Moskal]

On Wed, May 19, 2004 at 11:13:46AM +0200, Kamil Skalski wrote:
> 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

Trzeba będzie używać pełnych nazw w kompilatorze (S.R.MemberInfo lub
N.C.MemberInfo). Dodatkowo komuś z zewnątrz też może się to mylić (ej!
dlaczego to MemberInfo nie ma nic wspólnego z S.R.MemberInfo). Z drugiej
strony zamiast mylić może się kojarzyć :-)

> 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ę)

S.Type jest w S. a nie S.R. Pewnie w ogóle był tam od początku, zanim
S.R. powstało...

> 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).

array<int> *nie* ma TypeInfo. I nie wydaje mi się, żeby rezygnacja z
variantów w opisie typów była właściwa.

> 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.

Może by się dało. A co jest złego w tym, że implementują wspólny
interface?

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?