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

[Marc Lehmann <gtk-perl schmorp de>]

On Wed, Jan 07, 2004 at 07:39:23PM -0800, "Robert G. Werner" <robert inreachtech net> wrote:
> I'm not sure what you are trying to do here.  Your whole argument 
> seems to be that since gtk+ was implemented in a language that doesn't 
> have object oriented syntactic sugar,
   
Then you didn't understand my argument, possibly I wasn't clear enough
in representing it, so let me try to clarify these points.

First of all, I do not care about syntactic sugar (here). I do care about
semantics, ease-of-use and expectencies.

While C has not much in the way of syntactic sugar, it clearly does have
methods and functions, at least in glib and gtk+. This fact is well
documented.

> Perl shouldn't use the syntax it has to make the API more perlish.

To the contrary, perl _should_ use the syntax it has to make the API
more perlish.

The point here is that perl _does_ have functions, and functions are the
most common thing being used to represent functions, and to implement
the functionality implemented by the functions mentioned in the
subjects.

This, making these methods is not making the API more perlish, instead,
it's both making the API less perlish (being methods, which is very
uncommon, look at perl's builtin or the Encode module, for example), and
it's also making the API less similar to the C api, which alos doesn't use
methods here but functions.

Thus forcing them to be methods gives no advantage (at leats nobody ever
mentioned an advantage yet), but a lot of disadvantages, some of which
are very small (speed) some of which are large (inconsistent with both
documentation and existing practise in perl).

> That is very strange.  If people want to use the C api,  they are free 
> to write their apps in C.  However,  if they want to use Perl,  they 
> should be able to use Perl Idioms.

That is, incidentally, not one of the goals of the Gtk2-perl project
though, as you can easily verify. One of the goals was to make the API
similar enough to the C api so that documentation can be reused.

I do think that's not the best way to proceed, but I can accept this goal
as set by e.g. muppet. It's a valid way to proceed, and I am prepared to
adhere to that (I mean, I did so in the past and in present).

So what you think is "very strange" is, wether you like it or not, actual
policy for the Gtk2 module, not set by me, not advocated by me, but
reality.

However, in this case, both C API and pelr API (functions) coincide
perfectly with each other, and forcing tzhem to be methods is not perlish
(again, refer to builtins or some CPAN modules, you will see that the
cases were methods are used for simple functions are extremely rare).

> I can't see that you are very well informed about any work going on in 
> CPAN if you insist that making an API more Perlish is the wrong way to go.

Frankly, I am sure I am much better informed about any work going on in
CPAN than you, having published a large number of modules there, while I
can't see any published module there from you. So your ad-hominem
argument looks rather stupid to me.

In any case, you wrongly assume that abusing method syntax for functions
is more perlish, which I disagree with, and I honestly think most people
would do, given the enourmous amount of existing code that handles it
differently (and, not at all arguably more "perlish").

> Besides,  if you would really like a functional Gtk+ binding in perl, 
>  you are free to write one.

If I'd like that, yes. But I never asked for that nor mentioned that, so
why are you introducing this into this discussion?

> binding on CPAN.  Maybe people will like your functional interface 
> that requires passing pointers,  etc,  better.

Again, you seem much confused. functional interfaces don't require passing
pointers any more than oo interfaces. You seem very confused about how
perl works, and I suggets you stay out of this discussiun until you
learned basic concepts of programming and perl (like the fatc that there
are no pointers in perl).

> But the dicision on how to implement Gtk+2 in perl in this project was 
> made long ago.

Exactly, and that's why I think that departing from this decision by
breaking both the C and perl api is an extremely bad idea. You might not
agree with the original decision (or, probably more correct, you might be
confused about what the decision was), but I think it's important to stay
to it and not strive away needlessly, especially when not adhering to it
makes the interface less perlish and less documented.

> The guiding principles are there for all to read in 
> the archives of the list.

Exactly. So why don't you do that?

> It is silly for you to insist that using an Object Oriented interface 
> to represent Gtk objects in perl is wrong when the original 
> implementors of gtk talked about doing OO in C.

And it is silly of you to put words in my mouth I never uttered. What does
it buy you when you do that? I never, of course, claimed that, so why are
you spreading FUD that I did? Personally, I am most offended by people who
lie and badmouth others publicly, like you do.

> Basically,  until you show some code implementing your arguments,  I 

I did implement all of the code in question, mind you. However, it
recently was changed (or extended) in a bad way, and that's why I am
arguing here.

> think you are a troll.  And a pretty useless one at that.

... at least I do contribute! Do you?

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