GObjectification - GSoC progress as of June 16, 2013

[Gary Kramlich]

If you want to make a "final" in gobject, hide it's class an instance
structures in the .c only.  However, I personally believe that buddy,
group, chat, conversation, im, and even protocols should all be non-final.


On Thu, Jun 27, 2013 at 2:58 AM, Ankit Vani <a at nevitus.org> wrote:

> On 27 June 2013 13:09, Mark Doliner <mark at kingant.net> wrote:
> > Do we generally want our GObjects to be subclassable? I guess the
> > benefit is that plugins have more power to alter our behavior? And the
> > downside is that we have to be more careful not to break API?
>
> I think it's really up to us to decide exactly how much a core libpurple
> object
> can be subclassed. We decide which methods belong strictly to a class, or
> are
> virtual (which means we WANT subclasses to reimplement them) or pure
> virtual
> (subclasses MUST implement them). Subclasses won't be able to break
> existing API
> unless we intend it to. And in general I think it's a good idea to allow
> subclassing so that plugins can create their own variants of the core
> classes
> that can be reused by other plugins and can store data that the core object
> doesn't allow in a convinient way.
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130705/5fc483c4/attachment.html>