On Tue, 2 Jan 2007, Martin Peach wrote:
Mathieu Bouchard wrote:
but A_LIST can't work because the name "list" is already taken for a type of non-atom message. (an atom message is one carries exactly one atom which is always supposed to be of the type indicated by the selector)
A list is just a bunch of atoms laid out contiguously in memory: I guess that makes it a molecular message? ;)
That's the paradox. If a list is to be just a bunch of atoms, and you don't want to complicate the definition, but you want to support nested lists in a proper way, then you have to accept that an atom may be a list (or may represent a list via some kind of pointer, which amounts to the same...)
What about extending the pointer type so that it can point to any kind of atom, including a list of atoms?
That may be a good idea. I have the following questions about it:
- What do you do with the fact that an A_POINTER atom points to a
t_gpointer which points to a t_gstub ? Isn't that too much indirection for just a list? (The t_gstub may be skipped, but it's required in order to know whether we really are pointing to atoms!)
- What do you do with types of pointees? gpointers are expected to be
either pointer-to-array-element or pointer-to-scalar-in-glist (where glist is supposed to be canvas nowadays, but is still called glist in the source, even DesireData's). The assumption made by pointer-using patches is that if one has a pointer that is not null, then it points to a struct. Do you break the assumption that a pointer points to a struct, or do you introduce a way of looking at an atom as if it were a struct?
- Even though the gpointer type for scalars is GP_GLIST (meaning
"canvas"), the type of the corresponding fielddesc is DT_LIST, and the associated typename is the symbol "list"... what should be done about it?
- I'm really going to introduce plain refcounts already for another
reason, and I think that it would be important to not tie those new lists to a specific canvas, I want them to fly around in a carefree manner; therefore, should the list atoms be distinct from t_gpointer stuff, or should t_gpointer (as we know it) die? I'm open to either, really, and it's possible that both would happen - it needs not be either/or.
And also, here's a plan for making t_gpointer die:
Move gs_refcount to t_array and t_canvas.
add a t_pd header to t_array so that it can be recognised by its
t_class*.
- Remove gs_which because we can already figure it out: if (!gs_un) then
it's a GP_NONE, else we check whether *(t_pd*)gs_un == t_array_class to figure out whether it's GP_ARRAY or GP_LIST.
- nuke gp_valid, a_valid and gl_valid, because if they ever are useful,
they'll cause spurious warnings from valgrind, and because there are better ways of taking care of stale pointers. Note that the currently implemented gp_valid doesn't even work, because a_valid isn't cleared when freeing the t_array, so a matching a_valid is not a guarantee of whatever. I'd rather have pointers never go stale, by making deallocation completely automatic (refcounts and nothing else).
nuke t_gstub completely, by replacing gp_stub by gs_un.
at this point, the only remaining things are the element pointer
(gp_un) and the container pointer (gp_stub aka gs_un). If the unused portion of a_type is recycled (only compatible if no externals check for A_POINTER) then we could make it hold the index, but in the case of GP_LIST this wouldn't be efficient until t_glist stops holding its elements as a linked-list. If it does become efficient, then a_type may hold the gpointer index, and so t_gpointer will only need to store gp_stub, so t_gpointer can be nuked completely, by replacing w_pointer by gp_un.
Does that look good? (I admit that step 6 is more difficult, but I expect that DesireData's t_canvas/t_gobj will stop using linked-lists pretty soon
- they're getting too cumbersome to use, for some of the upcoming
features).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada