About ProgressReport and msn-pecan

[Kevin Stange]

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
>> it)
> 
> 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 
to 4.0.0.

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.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080615/ad411c44/attachment.sig>