[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