Re: cleanup proposal: get rid of GRealPtrArray, GRealArray

[Owen Taylor <otaylor redhat com>]

David Benson <daveb idealab com> writes:

> Hello, I know its getting late for these kinds of changes,
> but I was wondering if anyone wished to discuss making
> GPtrArray and GByteArray contain private members and
> then get rid of the ugly casting etc in garray.c?
> 
> The new structures would be
> 
> struct _GPtrArray
> {
>   gpointer *pdata;
>   guint     len;
> 
>   /*< private >*/
>   guint     alloc;
> };
> 
> struct _GArray
> {
>   guint8 *data;
>   guint   len;
> 
>   /*< private >*/
>   guint   alloc;
>   guint   elt_size;
>   guint   zero_terminated : 1;
>   guint   clear : 1;
> };
> 
> 
> Pros:
>   - makes the implementation much easier to understand.
>     (this line of reasoning was provoked by a friend asking
>     how GArray could possibly work since it didn't have the
>     element size around...  he could've figured it out eventually
>     by looking at the source, but the header file makes it look
>     rather magical)
> 
>   - exposes members which would be occasionally useful for debugging
> 
>   - [optional] we could support constructing these on the stack or inline
>     in objects for marginal efficiency gains
> 
>   - it's compatible with old sources and even binaries.
> 
> Cons:
>   - exposes members of the array class.  (i'm not sure i think this a con tho)
>   - goes against the original design of garray.  
> 
> Any supporters / detractors?


GRealArray, etc, are there to _hide_ the implementation details. 
You can always cast to GRealArray if necessary in a debugger.

Yes, we expose a lot of implementation details in GTK+ and a few
in GLib, but that is no reason to expose more here when we don't
need to.

There are many other things in GLib where the implementation is not
clear from a casual inspection of the header files. Think of it
as a challenge.

Regards,
                                        owen