better interfaces in idea docs; also better SLC docs + minor changes

This commit is contained in:
Richard Thier 2024-09-23 18:02:59 +02:00
parent c3001c4d52
commit 9212dfc814

102
BASED.md
View File

@ -62,9 +62,9 @@ Meg ez is (basic block-os módszer):
^^Ezek "kezelik" a memóriákat és resource-okat RAII-módon, konstruktorral és destruktorral.
Szerintem a struct-hoz és class-hoz képest is jobb szó.
Lesz továbbá tagged union is - lásd lejjebb - és interfészek (ami tagged union-á fordul le, hacsak ki nem optimizálja a fordító).
Lesz továbbá tagged union is - lásd lejjebb - és interfészek.
Szerintem itt a 'T' helyett talán érdemes csak egy interfész-nevet megengedni???
Szerintem itt a 'T' helyett talán érdemes csak egy interfész-nevet megengedni??? Esetleg nem is ilyen <..> stílusban?
# Placement new
@ -783,68 +783,24 @@ minden esetre kell legyen definíciója, vagy az únió eseteitől függetlenül
Zsolt vetette fel, hogy neki azért öröm töltené el a szívét, ha lehetne egy "kicsit OO style" azért annyiban, hogy egy tömbben tud
keverni különböző típusú dolgokat, amiknek közös az interfésze és kapni ilyeneket függvény paraméterként...
Ez valamilyen szinten jogos elvárás és az únió részben tudja is ezt, mert csinálhat az ember egy tagged union-t amiben ő maga
sorolja fel így a típusait amik a tömbben lesznek és a fun() függvényeikben simán this->fun() átírányít / delegál akkor.
**Megoldás**
No de! Ennél tudunk jobbat is! Mert ez nem kezeli azt az esetet, ha egy library-t akarok írni és ezt forrással együtt kiadni!
Ugyanis olyankor a lib írójaként én megszabom mely dolgokat veheti fel a tagged union - tehát előre kéne tudnom a use case-eket!
Ez nincs így! Ellenben a fordítót kihasználhatjuk arra, hogy generálja ezeket a tagged union-okat le, az alapján, hogy kik
implementálnak egy interfészt!
Lásd tagged union-oknál a "negyedik változat". Szerintem ez a legszebb!!! A tagged union tud implementálni interfészt és így
sokkal egzaktabban történik ugyanez "háttérben titkos tagged union generálás nélkül" - na így lett letisztult!
Első változat:
interface IStringifyable {
string stringify();
}
handle A implements IStringifyable {
...
}
handle B implements IStringifyable {
...
}
// Ez ilyenkor egy tömb, aminek az elemei igazából tagged union elemek,
// a build-ben meglévő összes azt implementáló dolog alapján...
void process(IStringifyable arr[]) {
...
}
Megj.: Szerintem ettől generic-szerűbb lesz a dolog, ha típusnak generik paraméternek adható egy "interfész"!
Olyankor csak konkrétan az interfész nevével (vagyis nem T implements IAkarmi, csak simán IAkarmi, de kiírható (ha 2 kell).
Továbbá simán amikor függvény paraméternek használjuk, akkor lehessen rajta "constexpr elágazni" a típusán!
Vagyis írhatunk ilyeneket:
handle<IStringifyable, IStringifyable2 implements IStringifyable> {
...
}
Vagy akár ilyet is (bár ezt kevéssé javaslom, de hasznos lehet):
void process(IStringifyable arr[]) {
switch(add.elemtype) {
case A:
...
case B:
...
}
}
Ifelni is lehet - olyankor például csak egy adott típusra valami speciális pluszt adni, kezelendő esetet...
Második változat:
Lásd tagged union-oknál a "negyedik változat". Szerintem ez a legszebb!!! A tagged union tud implementálni interfészt és így
sokkal egzaktabban történik ugyanez "háttérben titkos tagged union generálás nélkül" - na így lett letisztult!
+ ha nem tömbről van szó, akkor a hívási ponton az egy lightweight generic támogatás / ad-hoc polimorfizmus is (kell-e vajon?)
+ a hívási ponton az egy lightweight generic támogatás / ad-hoc polimorfizmus is! Emiatt elvileg generic se kéne!
Az interfészekre lehet többszörös öröklődés (egymás közt is, meg itt is).
FONTOS: A shared object-ek között NEM ajánlódnak ki ilyen jellegű típusok! Csak rekordok!
Megj.: A második változat (tagged union-os megoldás) kell szerintem + lehessen handle interfészelés!
Tehát egy handle is "implementálhat" interfészt és olyankor generikus kód keletkezik majd.
Ennél azt is szeretném, ha "tömbre" is működne, tehát IGameObject stuff[] paraméterrel a függvény
a hívási pontok alapján többféle módon is generatívan generálódik. Szerintem talán ki kell írni
ott, hogy IGameObject-like és interfész "like-olása" mindig ezt jelentené?
FONTOS: Adattagnak így nem lehet "interfész" típusa, csak tagged union-os esetben ugyebár...
## Láthatóság
TODO: Egyszeűsítendő?
@ -1532,20 +1488,20 @@ Máshonnan elérni így lehet, namespace-elés szerűen:
Ha nem szerepel több szó a definíciós első sorban az enter előtt / zárójelek előtt, akkor csak kódot tartalmazó "funkcionális" szó:
#: #just_code
#: just_code
#dup
#inc
#swap
#
#push(12)
#just_code
just_code
#intprint // 12
#intprint // 13
Vagy:
Vagy(zárójelen belüli futásra):
#: #just_code (
#: just_code (
#dup
#inc
#swap
@ -1661,6 +1617,7 @@ Ezt követően hívható a szó prefixelt változata
#intprint // 4
Megj.: A #builtin esetben mindig van elég byte hely majd a parzernek helyben átírni a szót a megfelelőre (whitespace-es törléssel)
Megj.: Erre nem kell külön runtime type - ezt lehet simán a deklarációkor helyben átfordítani!
## Névtelen szó - mégsem lesz!!!
@ -1747,6 +1704,7 @@ szöveges interfésszel, hanem simán csatornákkal és egy DAG-ot leírva, azé
char name[]; // inline! Tehát nem egy pointer! Zero terminált a whitespace / zárójel felülírásával.
char vars[]; // inline! Maga a tárhely is itt lesz! Elfér 4 byte ' @i,' vagy ' @j<EOL>' miatt!
char data[]; // inline! Előbb a változók, aztán a kód - így írható primitív forth-szavakkal is kódszó (pl. outputra).
char ender[]; // inline!
};
A szavakat az "ender" string terminálja, a hosszt itt alapból nem tároljuk. Amikor a parzer látja
@ -1769,21 +1727,24 @@ hasonló dolgokon túl! Amikor az első hívás történik, akkor megpróbáljuk
ideiglenes tárhely sem szükséges, csak egy plusz számítási menet, amikor még NEM csináljuk meg, csak kiszámoljuk mibe
kerülne és mennyi ram kell hozzá - kifér-e majd a jelen dolog helyére! Ha igen, akkor átírjuk + használjuk a stack-et.
Flag-ek:
Flag-ek (flags):
0. offset_top
1. offset_top
2. offset_top
3. offset_top
4. DEF_TYPE0: definíciós típus első bitje
5. DEF_TYPE1: 00: reguláris szó, 01: insertálóként definiált szó
6. TYPE0: a típus első bitje
7. TYPE1: a típus második bitje (00 - szöveg és futtatatlan, 01 - szöveg és futtatott, 10 - THREADED, 11 - internal (C ptr)
4. offset_top
5. offset_top
6. WORD_TYP0: a típus első bitje
7. WORD_TYP1: a típus második bitje
EDIT:
enum SLC_WORDTYP {
SLC_WORDTYP_TEXT = 0,
SLC_WORDTYP_NATIVE = 1,
SLC_WORDTYP_THREADED_SESSION = 2,
SLC_WORDTYP_THREADED_INLINE = 3,
};
Jelenleg úgy néz ki, hogy itt hét bitet is használhatnék - kérdés kéne-e vagy legyen még valami flag ott, mondjuk
egy továbbfejlesztési lehetőségként. Szerintem az utóbbi és akkor a data[] inline helyett a hossz után ptr lesz!
Mi az a "threaded kód"?
@ -1796,6 +1757,9 @@ Mi az a "threaded kód"?
Érdekes elképzelés lehet egy kifejezetten UTF8-szerű encoding is, hogy lehetőleg 8-16-32 bitet használjunk csak / szó!
FONTOS: A threaded kódot megpróbáljuk a lehető leghamarabb "process-álással" generálni a session-be, de ha nem tudjuk azonnal
a függőségek miatt, akkor ugyebár valamit tennünk kell, addig marad ahogy van...
Mint az egyértelmű, a szó deklaráció a kód szövegben legalább 4 byte-ot igénybe vesz és minden változó-deklarálás is!
* ':'