GObjectification - GSoC progress as of June 16, 2013
grim at reaperworld.com
Fri Jul 5 03:53:06 EDT 2013
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
> can be subclassed. We decide which methods belong strictly to a class, or
> virtual (which means we WANT subclasses to reimplement them) or pure
> (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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel