Re: [pdf-devel] Polymorphism on GNU Pdf

[Zac Brown]

-------- Original Message --------
Subject: Re: [pdf-devel] Polymorphism on GNU Pdf
Date: Sat, 04 Oct 2008 15:06:16 -0400
From: Zac Brown <address@hidden>
To: Juan Pedro Bolivar Puente <address@hidden>
References: <address@hidden>

Juan Pedro Bolivar Puente wrote:
> There are certainly some polymorphic types on GNU Pdf, the most clear
> example are stream filters and stream backends. However, although it is
> true that we must handle with C limitations on this point, I think that
> we are not doing it on the right way.
>
> I mean, it is cool to have a filter interface that we can handle
> homogenously, but it is not so cool if we need a
> pdf_stream_install_filter that gets a fixed enum to identify the
> filter... what if the library client wants to define a new kind of
> filter? He can't... Even worse, stream backends have a defined interface
> but we are using a switch () {} on every stream function to dispatch the
> correct one instead of using function pointers...
I agree, flexibility in a library like this is highly desirable.

> My proposal is to define a clear metodology for polymorphic types that
> makes the gnupdf API more consistent and that causes less coupling among
> modules. My purposed method is the one used by GNUlib data structures:
>
> *1.* Have a public structure that contains pointers to the
> implementation functions. For example:
>
> pdf-stm-filter.h:
>   struct pdf_stm_filter_impl
>   {
>     pdf_stm_f_init_fn_t init;
>     pdf_stm_f_apply_fn_t apply;
>     pdf_stm_f_dispose_fn_t dispose;
>   };
>
> *2.* For each polymorphic type, a global structure which is an instance
> of its implemetation structure, that encapsulates the information about
> its implementation. For example:
>
> pdf-stm-f-null.h:
>   extern struct pdf_stm_f_null_impl;
>
> pdf-stm-f-null.c:
>   struct pdf_stm_filter_impl pdf_stm_f_null_impl =
>   {
>     init: pdf_stm_f_null_init,
>     apply: pdf_stm_f_null_apply,
>     dispose: pdf_stm_f_null_dispose
>   };
>
> *3.* When some needs to create an instance of the polymorphic type, he
> gets a pointer to its implementation. For example:
>
> pdf-stm.c
>   pdf_status_t
>   pdf_stm_add_filter (pdf_stm_t stm,
>                       struct pdf_stm_f_impl* filter_impl,
>                       ...)
>   {
>     ...
>     pdf_stm_filter_t = pdf_stm_filter_new (filter_impl, ...);
>     ...
>   }
>
> pdf-stm-filter.h:
>   struct pdf_stm_filter
>   {
>     struct pdf_stm_filter_impl* impl;
>     ...
>   }
>
> pdf-stm-filter.c:
>   pdf_stm_filter_t
>   pdf_stm_filter_new (filter_impl)
>   {
>     pdf_stm_filter_t filter;
>     ...
>     filter->impl = filter_impl;
>     filter->impl->init (...);
>     ...
>   }
>
>   pdf_status_t
>   pdf_stm_filter_apply (pdf_stm_filter_t filter)
>   {
>    ...
>    filter->impl->apply (...);
>    ...
>   }
>
>
> This methodology is quite similar to the one we are now using on the
> filter's interface, but a little bit improved for decoupling's sake.
> What do you think?
Seems like a good idea to me. It might be worth doing this to the filesystem
interface as well. It might make it easier for people to write more fsys
implementations or even user defined ones. Just a thought, someone correct me if
I'm wrong :).

-Zac