Wunschliste:
Für (1) brauchen wir state, einen Zustand: Wir müssen uns merken, welche Datei wir bearbeiten. Es ist meistens nicht gut, Zustände in Modulen zu speichern – dafür haben wir Objekte. Zur Simulation einer Klasse definieren wir die Typstruktur:
static PyTypeObject Lookertype = {
PyObject_HEAD_INIT(&PyType_Type)
0, /* never mind */
"Looker", /* Name */
sizeof(lookerobject),
0, /* never mind */
(destructor)Looker_destroy,
(printfunc)0,
(getattrfunc)Looker_getattr,
(setattrfunc)0,
(cmpfunc)0,
(reprfunc)0,
0, /* as number */
0, /* as sequence */
0, /* as mapping */
};
Im Wesentlichen haben wir hier wieder eine Sprungleiste, in der verschiedene Standardmethoden stehen, die der Typ (die Klasse) so unterstützen sollte. Es gibt tatsächlich noch eine ganze Ecke mehr, die uns aber hier nicht interessieren.
Für uns wichtig sind erstmal nur getattr und destroy.
Das sind erst ein paar Methoden – wo stehen die Daten? Im lookerobject:
typedef struct {
PyObject_HEAD
int dflag, fflag;
int stringlen;
char *string;
char *comparbuf;
char *g_front,*g_back;
int fd;
int searchcount;
} lookerobject;
Das merkwürdige PyObject_HEAD expandiert zu Platzhaltern für z.B. Refcounts. Was da drin steht, interessiert uns nicht. Der Rest sind einfach die Nutzdaten. Wir können sie hier alle in C halten, würden wir hier Python-Objekte drin haben, müssten wir auf jeden Fall Refcounting betreiben.
Und wo sind unsere Methoden? Üblicherweise in einer weiteren Sprungleiste:
static struct PyMethodDef looker_methods[]={
{"look", (PyCFunction)Looker_look, METH_VARARGS},
{NULL, NULL}
};
Das ist aber nur eine Konvention, da der einzige Platz, an dem wir das brauchen, unsere __getattr__-Methode ist:
static PyObject *Looker_getattr(
lookerobject *self,char *name)
{
return Py_FindMethod(looker_methods,
(PyObject*)self,name);
}