Go to the
first,
previous,
next,
last section,
table of contents.
Gobjects (Generic OBJECTS) are mainly of interest to people writing
new modules for xlisp. Gobjects look to all xlisp code exactly like
normal objects, but they support in addition a hidden arbitrary-size
(and runtime resizable) binary data segment which may be used to store
whatever your heart should desire.
The various array classes provided by the Skandha4 3d module are all
built on top of the facilities provided by the Gobject module.
Gobjects are useful whenever you want to store data in C format, but
still have it accessable in xlisp and garbagecollected like a normal
xlisp datum. Reasons for doing this include:
-
To save space. If you have megabytes of floating-point data, you may
be able to save a factor of four in ram by storing it in binary instead
of as normal xlisp data.
-
To save time. If you have megabytes of floating-point data, you may
be find it significantly faster to whip down an array of C floats,
rather than extracting values from a lisp array, checking the type
on each to verify that it is indeed a float and so forth.
-
To provide data hiding. Normal xlisp datastructures are all too
easy for errant programmers to get their fingers into. Storing
in xlisp-invisible space can provide considerable confidence
your data isn't being read without your knowledge.
-
To provide data integrity. Storing in xlisp-invisible space and
providing your own accessor functions can make it easier to maintain
important invariants.
-
To conform to externally imposed data layouts. If you want to have
objects in xlisp holding structures defined by <sys/time.h> or whatever,
you can tuck the structures in question inside instances of appropriate
subclasses of Gobject, privide xlisp messages to access the contents
using the system-provided access fns/macros, and never have to actually
know the layout.
In memory, a gobject has three basic segments, which in order are:
-
The usual LVAL slots which any object would have. The number depends
on the class definition of the object.
-
A vector of LVALs. The length of this vector defaults to zero,
but you can change it after the object is created. Messages
are provided for fetching and storing LVALs into this vector.
-
A binary data segment. The length of this segment defaults to zero, but
you can change it after the object is created. Messages are provided
for fetching and storing from this segment while treating it as bytes,
integers, floats, or doubles. Nothing stops you from storing a value
into the segment as a double and reading it back as bytes.
NOTE that this section does not document facilities gobject
provides at the C level, only those visible at the lisp level. For now,
you must simply read the source to find out what is available in C.
NOTE that the GOBJECT module actually exports two classes,
GOBJECT and CLOSED-GOBJECT. These differ only in that CLOSED-GOBJECT
provides no messages to read, write, or resize the LVAL and
binary segments. GOBJECT can be useful for off-the-cuff hacking
entirely in xlisp. CLOSED-GOBJECT is usually used as the parent class
for new hybrid classes coded up in C, since it restricts the xlisp
programmer to whatever accessor functions you choose to provide.
NOTE that while separate messages are provided for accessing the
binary segment of a gobject as bytes, floats etc, all of these
messages access the *same* binary segment. If you change the size
of a gobject using :BYTE-ADJUST-ARRAY, you change its size as
measured by all of:
:BYTE-ARRAY-DIMENSION
:INTEGER-ARRAY-DIMENSION
:FLOAT-ARRAY-DIMENSION
:DOUBLE-ARRAY-DIMENSION
You do not change the :LVAL-ARRAY-DIMENSION, however, since LVALs
are not stored in the binary data segment, but in a separate LVAL
segment (since they must be kept separate for the garbage collector).
Go to the
first,
previous,
next,
last section,
table of contents.
