[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