Re: Binding convention for poorly named functions

["Ross McFarland" <rwmcfa1 neces com>]

muppet said:
> James Curbo said:
> > Torsten Schoenfeld wrote:
> > | As risky as it might be, I'd vote for keeping up the method approach
> > | simply for the sake of consistency.  And for changing all those bad boys
> > | to helper functions in Gtk3.
> >
> > This gets my vote, for the same reasons. It would be utterly confusing
> > to newbies to have some functions as helpers and some as methods. I do
> > totally support splitting them out in the next major version, however.
>
> The rebuttal is, of course, that it is sacrificing maintainability and
> correctness for consistency.  In the future, if a new method pops up in the
> namespace in which we've squatted, we will be screwed and forced into an API
> change, which is worse than being inconsistent.
>
> So, clearly, i cannot choose the wine in front of you.[1]
>
> Doing the wrong thing to avoid surprising newbies seems rather dubious; it's
> going with PoLS from the uninitiated side (it acts like the others), but
> violating it from the other side (it isn't actually what it says it is).
>
> We will be stuck with any broken APIs until gtk+-3.0 and Gtk3, and there's no
> telling how far away that is.  They already have plans for gtk+-2.6, there may
> be 2.8 and even 2.10 for all we know.

as before i dissaggree with you about this and aggree with the two previous
viewpoints. if we'd gone from the begining and done methods as methods and
functions as functions it would be different. but the mix and match stuff just
sucks in all cases. i know it may run into name space clashes, but those will
be pretty rare, less so than the likelihood of running into a function
implemented as a function and the programmer expecting it to be a method b/c
95% of the time it is. reguardless it's probably too late b/c we're releasing
mix and match stuff into api stable/frozen world.

-rm