About ProgressReport and msn-pecan
kstange at pidgin.im
Sun Jun 15 08:12:40 EDT 2008
Felipe Contreras wrote:
> On Sun, Jun 15, 2008 at 1:58 AM, Tim Ringenbach
> <tim.ringenbach at gmail.com> wrote:
>> What's the end goal here? Just to speed up compiling and make the
>> graph shorter, if technically misleading? (By misleading I mean the
>> account module really does use the presence module even though it
>> wouldn't show on the graph anymore because the header isn't including
> No. The public and the private fields are two completely different things.
> Try to use "hash->size" with GHashTable; you can't. Why? Because you
> shouldn't need to know what is being used internally, actually ->size
> is not what you would want, you need "hash->nnodes", but you don't
> need to care, you just use g_hash_table_size.
We understand this sort of design, which is the end goal of
gobjectification and/or use of accessor functions.
> Similarly, you don't need to know about GHashNode; it's something
> *internal*. if they choose to define that in "ghashnode.h" or
> "ghash_private.h" shouldn't matter, because you shouldn't use that
> directly. You might find surprising that GHashNode is not available in
> any header file, ever. That's a clean modularization.
There's no need to use the "*_private.h" headers. If we don't want to
be accessing data structures directly, we should just define them
privately and use them in a standard way. I believe that's the
intention in code going forward.
> What is _misleading_ is that you need to know all the internal details
> of Presence; you don't, you just need the public API. Actually, I just
> checked and Presence is properly hiding the internal details, but not
> Account, nor Proxy which is used by Account.
So you see, we are already doing this. Presence was completely
rewritten for 2.0.0. Account and proxy code are old and their API did
not change much from the 0.x to 1.x to 2.x series. It was not revamped
to hide internal struct details, and most of the other areas have not
either. That doesn't mean it can't be, but hiding the structs now is an
API and ABI breakage and cannot be done without bumping to 3.0.0. If we
want, as stated, to move to gobjectification, or even if we don't, this
can certainly be a goal for 3.0.0. Good patches would be welcome, but
if we can get movement on gobjectification, it would be better to
combine the process into one step, otherwise we're pushing something off
However, I think the _private headers have no use at all and we can
accomplish the same improvements without having them clutter up the
source tree. Nothing in other source files should need to access the
members of a struct if the API for the objects is complete.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 260 bytes
Desc: OpenPGP digital signature
More information about the Devel