[nem-pl] Kilkla temacików

[Kamil Skalski]

Sunday 04 of January 2004 17:40, Michal Moskal wrote:
> On Sun, Jan 04, 2004 at 12:48:45PM +0100, Kamil Skalski wrote:
> > u nas musiałoby to wyglądać
> > f (params l : array(int)) : void
> > ew.
> > f (params l : list(int)) : void
> >
> > (dodanie słowa kluczowego 'params' nie podoba mi się za bardzo...)
>
> Albo f (.. l : array (int)). Ale nie wiem. Wersję z list bym sobie

no tak, ale skoro już stwierdziliśmy, że zrobimy jak w C#, to nie wracajmy do 
starych pomysłów

> darował, tak, żeby na zewnątrz była widoczna zawsze tylko wersja z tablicą
> (zgodna z CLS).
>
> > > 2. zrobić jakiś hack w parserze, że jak widzi "macro ... syntax ..." to
> > >    wtedy już dodaje regułę. problem: makra muszą być sparsowane przed
> > >    funkcjami, które z nich korzystają, o co musi zatroszczyć się
> > >    użytkownik (kolejność plików i funkcji w nich).
> >
> > No właśnie o czymś takim myślałem i to nie jest aż taki hack. W H. nie
> > takie hacki mają ;)
> > Ale najładniej byłoby dodać jeden przebieg do kompilacji, który wyłapałby
> > wszystkie macra i pododawał rozszerzenia składniowe.
>
> Osobny przebieg *parsowania*. Zauważ, że musiałbyś mieć hack w rodzaju
> liczenia otwartych/zamkniętych nawiasów zamiast normalnego parsowania
> (bo nie wiesz, że masz np. takie while jakoś inaczej parsować).

W zasadzie to makra będą tylko w toplevel, więc przy odpowiednim 
uporządkowaniu parsowania (najpierw wszystkie deklaracje, potem wyrażenie) to 
powinno być jednak wykonalne. Makra operujące na deklaracjach zrobi się jako 
te atrybuty 
[xmlize] class Player {...}
więc w zasadzie nie powinno być problemów - nie będziemy zmieniali składni 
parsowania niczego w toplevel.

>
> Dodatkowo wpłynie to negatywnie na czas *każdej* kompilacji, nie ważne
> czy tworzącej makra czy nie (a pewnie większość będzie takich, które
> makr nie tworzą).
>
> > Jeszcze jedna sprawa - opcjonalne parametry.
> > assert (cond : expr, message : string_lit = "") { .. }
> > To w ogóle byłoby fajne, a cytuję:
> > "C# doesn???t provide a way of directly doing so, despite the fact that
> > VB.NET and .NET???s attribute system both support this functionality.
> > This is a subject of some debate currently in the C# community."
> >
> > Myślę, że możemy zrobić to po prostu tak jak w C++
>
> W C++ o ile się orientuje opcjonalne argumenty są przekazywane z
> call-site. Tzn. foo (bar) jest zmieniane na foo (bar, ""). My moglibyśmy
> przeładować foo (znaczy wygenerować funkcję foo (x) { foo (x, "") }).
> Problem może być jednak taki, że takich przeładowań trzeba wykładniczo
> dużo względem liczby argumentów (w C++ jest ich tylko liniowo dużo bo
> argumenty można opuszczać tylko od końca, podczas gdy u nas przez
> keyword parameters dałoby się też ze środka). Więc chyba lepiej tak jak
> w C++.
>
> Można też zastanowić się nad oróżnieniem foo (bar) od foo (bar, "")
> (tj.  nie podania default argumentu, od padania go akurat w formie
> defaultowej). Można by to kodować jako option. Ale to nie ma chyba
> głębszego sensu.

Hehe, darujmy sobie takie komplikacje:
1. params może być tylko jako OSTATNI parametr (w C#) i my też tak to zrobimy, 
bo zresztą inaczej jest niejednoznacznie
2. opcjonalne parametry też zrobimy po ludzku, czyli tylko ostatnie
3. podobno C#powcy przyznają, że opcjonalne parametry to tylko cukier 
syntaktyczne na overloading i że można je sobie zrobić właśnie pisząc kilka 
wersji danej funkcji. Wydaje się, że nie ma nawet sensu "tworzyć" tych 
liniowo wielu nowych funkcji, tylko zakodować ten mechanizm w overloading 
enginie.

>
> Oczywiście opcjonalne argumenty w makrach to tylko kwestia składni i
> jakiegoś preprocessingu.

Ale fajnie byłoby mieć to wszędzie - to często ułatwia dostosowywanie API do 
zmian, bez konieczności przerabiania całego kodu.