Re: [RFC] Glib::filename_(to|from)_unicode => Glib->filename_(to|from)_unicode?

[Marc Lehmann <gtk-perl schmorp de>]

On Thu, Jan 08, 2004 at 08:55:51AM -0500, Ross McFarland <rwmcfa1 neces com> wrote:
> once again the filename stuff obviously isn't the best example, but some good
> examples (of places where class static functions have to be accessable though

Yes, the example is flawed because new methods are new _methods_.

Object oriented programming is about objects, semantics and a way of
thinking. It's not about syntax, as gtk+ (implemented without OO syntax)
clearly shows.

The problem is that you want to force a paradigm (objects) onto
functions where it clearly doesn't make sense. The original designers of
glib knew this, that's why they used functions not methods.

You also see that something is wrong because you fail to give a reasonable
example ("the filename stuff obviously isn't the best example"). The
reason for that is that there are no objects involved, certainly not the
Glib object (or class).

So forcing a paradigm here is wrong. It is also confusing, since both in
C and in Perl people are used to do functons with functions (a very close
example is Encode::encode, which serves a very similar purpose).

Another example are the PANGO_* constants. People simply _do not_ expect
to have to use Gtk2::Pango->scale instead of the documented PANGO_SCALE.

So if you force methods in the case of the filename conversion functions,
I would request that the PANGO_* constants would also be reverted to their
former method-only form.

Otherwise, please answre why you want to force method paradigm on
non-methods here but not in other areas? I have no answer for that.

The whole problem here is that people again and again claim that the
original fucntions are methods, but they aren't, and inheritance makes
no sense at all sicne no objects or classes are involved. It's simply a
non-issue.

> there is a sligh difference in what is going on here, but we can't rule out
> the possiblity that someone will want to make their own child of Glib::Idle,

There is a problem here, too, now that you mention it. You are abusing a
perfectly fine principle (objects and methods) here.

In languages that have no functions, this makes sense, and as a design
principle, it could be implemneted like that as well. But this is not the
case either, as in your example, a class is involved (Glib::Idle), while
the changes to the filename functions involve no class, just a package.

Your might argue that they are syntactically the same, but the point is
that Glib does not bundle any generic functionality that has a common
class. It is simply senseless.

In short, the change to the filename functions to make them methods of a
ill-defined Glib class with no clear semantics is a plain and simple
design bug.

Instead of adding more ill-defined contortions like adding random
"methods" to some random "Glib" class, we should first sort out which
decisions and design principles are to be applied.

In this case there are at leats three conflicting design goals (make it
perlish, adhere to the C documentation, make everything methods). I'd
say the last of these principles makes least sense, since it's the only
principle that has no direct merit.

And if you want to break some of the goals here when it makes no sense
"just to be consistent" then please do so with the other areas where
people have applied sensible translations of the C API as opposed to
blindly making everything the same.

> or whatever. that's not for the binders to decide, and to support this we must
> use the -> syntax.

But you already don't in other areas, and this perfectly makes sense.  You
can only give examples that work with methods so far, and agree that they
don't apply well to the filename functions. I can back up my position both
by project goals and by existing practise in Gtk2, perl and C.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg goof com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |