[GSoC] GObjectification Summary

Ethan Blanton elb at pidgin.im
Sun Dec 1 23:02:45 EST 2013


Mark Doliner spake unto us the following wisdom:
> > The function returns a static array of primitive scores that nothing else
> > outside the statuses subsystem would require. This got a little ugly because
> > of the splitting of PurpleStatus and PurplePresence into two seperate files,
> > but I don't really see a point in exposing a function to the public, that
> > returns an array for which no documentation is available to the public.
> >
> > Do you think I should make it public anyway?
> 
> Hmm. I guess this question doesn't have an obvious answer. I see your
> point about not wanting to make the functions public., but I'm also
> not a fan of calling functions in other files when those functions
> aren't listed in a header file. It feels messy. I guess I mildly
> prefer listing them in our public header file, even if that exposes
> them to third parties. But please don't let me be the final decider.
> Please use your own judgement and/or check with Ethan or other Pidgin
> devs.

Declaring it in libpurple/internal.h seems like the correct answer
here.  I think it's pretty clear that anything in libpurple/internal.h
isn't part of our contract.  There are a number of other _functions
there already.

Ethan



More information about the Devel mailing list