Commit eaeb0983232d6c447714dc7746443f5bfc297fd9
1 parent
f366c0b8
added some valueable thought about cclass and how this structure might evolve to a real class
Showing
1 changed file
with
98 additions
and
0 deletions
doc/cclass-thoughts.c
0 → 100644
1 | +/* | |
2 | + * Was wir unter C tun müssen ist separate definition von Interface und | |
3 | + * und Daten sowie Methoden....das Interface ist dabei immer verantwortlich | |
4 | + * dafür die zur Klasse gehörende Implementation einer Methode aufzurufen. | |
5 | + * | |
6 | + * In anderen Worten... eine Klasse ist eine konkretisierung eines | |
7 | + * Interface. Ebenso wie es viele Objekte einer Klasse geben kann, kann es | |
8 | + * auch viele Konkretisierungen eines Interfaces geben. | |
9 | + * | |
10 | + * Alle Klassen die das gleiche Interface konkretisieren reagieren auf | |
11 | + * die gleichen Messages und Objekte dieser Klassen sind daher grundsätzlich | |
12 | + * austauschbar. | |
13 | + * | |
14 | + * Ein Interface kann ebenso wie Klassen andere Interfaces erweitern. | |
15 | + * Objekte von Klassen die ein solches erweitertes Interface konkretisieren | |
16 | + * koennen auch überall dort eingesetzt werden wo Objekte des Basisinterface | |
17 | + * eingesetzt wurden. | |
18 | + * | |
19 | + * Alles Interfaces müssen wenigstens von dem Basisinterface struct _CCLASS | |
20 | + * abgeleitet sein, welches __construct und __destruct sowie class detection | |
21 | + * Magic und die Klassengroesse enthält. | |
22 | + * | |
23 | + * Die Interfaces können zur compilezeit statisch initialisiert werden da | |
24 | + * sie sich zur laufzeit nie ändern. | |
25 | + * | |
26 | + * Über die implementierung multipler interfaces muss ich noch nachdenken. | |
27 | + * Denkbar waere den Interfaces reservierte namen zu geben über die dann immer | |
28 | + * auf sie zugegriffen werden muss...hat eine Interfacedefinition dann ein | |
29 | + * memder dieses reservierten namens hat er auch das Interface. | |
30 | + * | |
31 | + * === was folgt ist noch nicht in unten stehendem pseudo code === | |
32 | + * | |
33 | + * Die interfaces sollten sich evtl nicht extenden....stattdessen | |
34 | + * sollte die Klassenimplementation ihr interface mit den existierenden | |
35 | + * Interface definitionen und ihren implementationen initialisieren. | |
36 | + * | |
37 | + * Das soll heissen zu jeder Klasse (A) wird auch eine Interfaces structur | |
38 | + * angelegt die dann konkrete Interface Instanzen initialisiert und mit | |
39 | + * einem unique name versieht. | |
40 | + * | |
41 | + * Dabei ist dann verprflichtend das zumindest das CCLASS interface | |
42 | + * eingebunden wird, damit es wirklich eine Klasse wird. :) | |
43 | + */ | |
44 | + | |
45 | +// === INTERFACE DEFINITION ======= | |
46 | + | |
47 | +typedef void (*fptr_draw)(void *); | |
48 | + | |
49 | +typedef struct __SHAPE { | |
50 | + struct _CCLASS cclass; | |
51 | + struct { | |
52 | + fptr_draw draw; | |
53 | + } shape; | |
54 | +} * __SHAPE_PTR; | |
55 | + | |
56 | +struct _SHAPE; | |
57 | +typedef struct _SHAPE * SHAPE; | |
58 | + | |
59 | +// === INTERFACE IMPLEMENTIERUNG (for dynamic binding) ======= | |
60 | + | |
61 | +void * draw(const __SHAPE_PTR shape) | |
62 | +{ | |
63 | + const __SHAPE_PTR class = _object - sizeof(void *); | |
64 | + | |
65 | + if (shape && class && class->draw) { | |
66 | + class->draw(shape); | |
67 | + } | |
68 | +} | |
69 | + | |
70 | +// === KLASSEN IMPLEMENTATION ======== | |
71 | + | |
72 | +static void draw(CIRCLE * this); | |
73 | + | |
74 | +static | |
75 | +const | |
76 | +struct __SHAPE _circle = { | |
77 | + { | |
78 | + CCLASS_MAGIC; | |
79 | + sizeof(struct __SHAPE); | |
80 | + __construct; | |
81 | + NULL; | |
82 | + __destruct; | |
83 | + NULL; | |
84 | + NULL; | |
85 | + }; | |
86 | + { | |
87 | + draw; | |
88 | + } | |
89 | +}; | |
90 | + | |
91 | +static | |
92 | +void | |
93 | +draw(CIRCLE * this) | |
94 | +{ | |
95 | + /* draw the shape */ | |
96 | +} | |
97 | + | |
98 | +// vim: set ts=4 sw=4: | ... | ... |
Please
register
or
login
to post a comment