Re: Binding convention for poorly named functions

["muppet" <scott asofyet org>]

Ross McFarland said:
> muppet said:
> > 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.
>
> 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.

fine, we've released functions as methods, so it would be incongruous to start
adding functions.

that doesn't mean we can't make poorly-named functions be class static
methods, in the namespace of the adding library, not the target "object". 
this will give you the consistent method syntax while avoiding the possibility
of namespace clashes.

  /* the offending C function: */
  some_naughty_function (other_object, ...)

  # correctly as function (i'm the only one in favor of this, i suppose)
  Some::Naughty::function (other_object, ...)

  # as a method (i think this is completely wrong)
  $other_object->function (...)

  # as a method with a nasty name (just as wrong, and ugly)
  $other_object->some_naughty_function (...)

  # as a static method (consistent with how we've done things in the past)
  Some::Naughty->function (other_object)


For the Gnome2/Gtk2 menu->attach problem from a short while back, you'd have

  gnome_popup_menu_attach (gtkmenu, ...)
  Gnome2::PopupMenu->attach ($gtkmenu, ...)


-- 
muppet <scott at asofyet dot org>