[nem-pl] Rozszerzenia - myśli o kompilacji

Michal Moskal malekith at pld-linux.org
Tue Oct 28 22:48:31 CET 2003


On Tue, Oct 28, 2003 at 10:23:32PM +0100, Kamil Skalski wrote:
> Dziś zawiązała sie dyskusja z Michałem na temat kompilowania rozszerzeń i 
> miejsca umieszczenia ich w kodzie.
> 
> Jego stanowisko początkowe:
> - wszystkie rozszerzenia będą pisane w osobnym pliku
> - będą uruchamiane opcją kompilatora, np.
>   nemerle -enable-extensions p.n -o p
> lub co gorsza
>   nemerle -extensions ext.o p.n -o p

Oj, zdecydowanie gorsza. Właściwie to powinno być raczej coś takiego:

foo.n:
use extension Printf;
use extension My_tools;
...

I to by szukało plików Printf.dll oraz My_tools.dll w kilku lokacjach
(bilioteka standardowa, aktualny katalog etc). Dodaktkowo kompilator
zakładałby "use extension Std;" tak o. W tym Std pewnie powinien być ten
Printf więc to jest średni przykład, ale łapiecie o co chodzi.

> Moja wizja ;)
> - rozszerzenia można pisać zawsze i wszędzie
> - kompilują sobie one wszystkie funkcje, które są potrzebne i korzystają z 
> nich przy compile-time uruchomieniu
> - standardowe rozszerzenia (czyt. zawarte w standardowej bibliotece) są zawsze 
> włączane (ew. według zapotrzebowania) automatycznie, a te własne, z których 
> programista korzysta są wyszukiwane (lub dokompilowywane) z plików projektu, 
> czyli taki linking online na potrzeby kompilacji
> - użytkownik nie ma pojęcia czy używa zwykłej funkcji czy rozszerzenia

Użytkownicy dzielą się na dwie podkategorie:

  a) tacy co będą pisać rozszerzenia
  b) tacy co nie będą pisać rozszerzeń

Możemy spokojnie założyć, że grupa b) przewyższy grupę a) 10-krotnie. Od
grupy a) chciałbym wymagać, by wiedzieli czym różni się wykonanie kodu w
kompilatorze od wykonania w czasie ergh... wykonania.

Ale to jest moje zdanie i być może możliwość mieszania kodu z metakodem
nie jest zła.

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




More information about the devel-pl mailing list