Re: [pdf-devel] Binary compatibility

[jemarch]

     2) "Hide" the structures to the library user: Which means several
        things, as stated before:

        a) Use heap-allocated objects, so the client code is not the one
           who needs to know the size and composition of the
           structures.

Not all the ADTs implemented in libgnupdf are allocated in the
heap. Some pdf_foo_t values are structures, not pointers.

Remember the case of pdf_point_t (in a two dimension cartesian
space): it is small and it is likely that we are going to need to use
a lot of them. As you said in your previous email we could make an
exception with those ADTs.

        b) Never allow the user to access structures directly (forbid
           the operator . or ->), because for that compiler must know
           how the structure is organized, something that is often
           break when changed. Use accessor functions.

That's fine. It is the policy we are following right now. That means
that for the vast majority of the existing pdf_foo_t we could use
forward references in pdf.h.

        c) Totally hide the structure to the compiler, by just giving
           to it a forward-declaration and the defining it in the .c
           that actually creates the instances, so we don't tempt it
           to make weird optimizations based on his knowledge about
           the structure or the user to see it (the distributed .h
           headers would no contain any information about the
           structure).

I think that I like this idea, but I would like to hear the opinion of
other people before to take any decision about this issue.

Aleks, Gerel, Zac, what do you think about this?