Proposals for 3.0.0 API changes

[Richard Laager]

On Sun, 2007-12-30 at 22:02 -0500, John Bailey wrote:
> In the msn-pecan thread, Gary and I agreed that an API freeze after 2.4.0 in
> order to implement struct member hiding would be a good way to help us on the
> road to having libpurple's objects implemented purely as GObjects.  Ka-Hing
> voiced support for the proposal.

I'm not necessarily opposed to this, and I think it'd be great for
things (as I mentioned in my other e-mail here).

That said, I'd like to suggest an alternative for discussion:

"Struct member hiding" means moving the struct definitions from the .h
files to the .c files, correct? What if we did the following:

For each struct:

	1. Copy the struct definition into the .c file and wrap it with #ifdef
PURPLE_HIDE_STRUCTS.

	2. Wrap the struct definition in the .h file with #ifndef
PURPLE_HIDE_STRUCTS.

	3. Compile with CFLAGS=-DPURPLE_HIDE_STRUCTS and fix up references to
that struct?

Alternatively, we could use PURPLE_DISABLE_DEPRECATED there or make it
imply PURPLE_HIDE_STRUCTS.

If we did that, we could do the struct hiding one struct at a time on a
branch and then propagate to trunk as we went. It wouldn't break API
compatibility because the public headers would have the definitions by
default.

Once the struct definitions were fixed, it'd be much easier to do the
GObjectification. We could do that on a branch and when it was done,
release it as 3.0.0 with all the deprecated stuff dropped.

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20080102/e8bc4825/attachment.sig>