[nem-pl] Propozycja zmian w API kompilatora

[Kamil Skalski]

Wednesday 19 May 2004 11:25, Michal Moskal wrote:
> 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ć :-)

Myślę, że kojarzenie jest przeważającym argumentem. Nie sądzę, aby ktoś używał 
(poza naszym kompilatorem) jednocześnie Nemerle.Compiler i System.Reflection 
- a jeśli będzie, to raczej będzie znał różnicę.
Poza tym, jeśli uda się API zbliżyć także wewnętrznie, to kojarzenie będzie 
miało jeszcze większe znaczenie.

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

No dobrze, to my nie zrobimy tej samej niekonsekwencji. Tym bardziej, że u nas 
ten Type/IType/TypeInfo będzie używany na zwenątrz do tego samego go 
FieldInfo

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

No to co zwraca def x= array [1]; x.GeType? Ale być może reprezentacja 
wariantowa jest dobra.

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

Jest mały problemik, bo jak makro dostaje TypeInfo i w nim pyta o typ 
memberów, to nie dostaje już TypeInfo, tylko IType. To może być nieco 
confusing - no ale taka już natura, niektóre typy są external a inne własne.

Kamil