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

[Marc Lehmann <gtk-perl schmorp de>]

On Wed, Jan 07, 2004 at 05:58:33PM +0100, Torsten Schoenfeld <kaffeetisch web de> wrote:
> > - is totally unlike any other perl module, it's unperlish
>
> It's too late for that argument.

I think not. Correcting bugs might be painful, but it's never too late.
It might be too painful, or take a lot of time (or a generation, like Gtk
=> Gtk2!), but it's never too late.

> *Everything* in gtk2-perl-xs uses that syntax.

Untrue... Also, the argument "we did it wrong before so we need to do it
wrong in the future" is not convincing.

> > - it is totally unlike the C syntax, and changing the API is
> >   not a goal of gtk2-perl, now is it?
>
> I fail to see how the arrow syntax is any more different from the C API
> than the colon one.

It's a function in gtk2+, not a method. The same should be true for
perl, simply because it's expected by perl AND by C programmers.

So translating the function as a function is faithfully duplicating
the C API in perl, which is the goal of Gtk2. It is _also_ the way you
would normally do it in perl, so making it a method is introducing
incompatibilities to the C api while making it more difficult for perl
programmers alike.

> > - it's unneeccary slow
>
> We already showed that the speed difference is negligible.

That doesn't invalidate the correctness of that argument. The speed
difference might be unnoticable in actual applications.

You forgot that I am in favour of this syntax, so the above only shows
that by following my suggestions, not only do you get a saner and more
faithful API, you also get a small speed improvement "free of charge" :)

> > - disallows compile-time-checking (a great minus of the gtk2 API
> >   over gtk1, don't increase this problem needlessly)
> > - it's confusing to users
>
> All you ever got from gtk2-perl-xs was a check for the correct number of
> arguments.

Ehrm, hello, earth calling? gtk2-perl-xs always checks ALL arguments, but
not at compile time, only at runtime.

Most perl modules allow checking at compiletime for flags and
enumerations, for example.

In both "usual" perl and in C, you just use this:

   xyz PANGO_SCALE

This can be checked at compiletime. In Gtk2 you had (past tense) to do
this:

   xyz Gtk2::Pango->scale

Which cannot be checked at compiletime for correctness.

> I think that is what Perl5 programmers expect.

And I argue that this is completely wrong, just look at CPAN. Some things
cannot be checked at compiletime, but the things that can, usually are.

> certainly don't expect that passing an array (@a = qw(bla bla bla)) to
> filename_to_unicode results in an return value of "3".

It's documented that way both in C and in perl. One goal of the Gtk2
"project" is the keep the API similar, to reduce surprises and fulfill
expectancies. From that standpoint, it's least unexpected.

Also, you cannot pass arrays as arguments in perl, so your claims about
anything "expected" in this case are rather useless, as it cannot be done
in perl.

Please note that scalar context is rather common with builtin functions,
too (chr, lc, abs...). I'd say it's very uncommon for builtins or
modules to have string functions accept multiple arguments. I haven't
found a single string builtin that accepts list context, actually. Have
you?

So why do you claim that behaviour not found in perl itself can actually
be expected? As a perl programmer myself, the least unexpected means "like
everybody else" (if there is a pattern).

> > - it's awkward to use
>
> I fail to understand why "->" is more awkward to type than "::".

But it _is_ more awkward to type, on my keyboard, the fact that it's two
different characters, and the fact that I need extra parentheses. If you
fail to see this, it's not your problem.

> If everything in a certain module used one syntax and only two methods
> used another one, *that* would be awkward!

Sorry for thesse plain words, but that's bullshit. Using the same syntax
for everything is extremely uncommon, precisely because it's usually
very awkward to use. For example, you don't program by typing in only
digits, because, although the syntax would be very simple and the same for
everything, it's obviously not very userfriendly.

Using the same syntax for different things (here methods and functions)
is usually a problem for people, especially when they are used (by
environment, here perl) to different syntax for these things.

There is simply no merit in forcing everything to be a method (constants,
functions, whatever) unless there are good reasons for it (e.g. "perl only
allows methods"), but IMHO all these do not apply, because perl _does_
differentiate between methods and functions in the same way as C does, and
does so in the same way as many modules and builtins.

For example, character encoding conversion (which is what we are talking
about) is handles by perl using functions, too.

So again, and lastly, it's a function in C (and one goal is to stay
compatible to C as long as it's sane), the same functionality _is_ handles
by functions in perl itself, it is the way perl programmers must expect
things, since perl itself handles it that way, a function is slightly
faster, less to type etc...

Compared to these, you only brought in bogus or simply wrong arguments.
I have yet to see convincing arguments on why to break both one of the
fundamental goals of the Gtk2 project _and_ existing practise by forcing
these functions to be methods.

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