Re: Do we have to worry about the names of generic functions?

[Rob Browning]

Andy Wingo <address@hidden> writes:

> I have a question for people, the answer to which will hopefully lay to
> rest a lot of namespace-related debate. That question is, do we have to
> worry about the names of our generic functions?

I just asked basically the same question on guile-devel, not realizing
you'd already done so here :>

> * Generics clobber the namespace.

> To put it another way: what's the difference between (output x) and the
> more smalltalk-like (x 'output)? The argument above leads to the
> conclusion that there is no difference, and therefore that generics do
> not clobber namespaces.
>
> Is there a hole in that argument?

One thing to consider is that at least in CLOS (and I'd presume GOOPS,
though I'm not as familiar with it), there are more sophisticated
multiple argument dispatch and multiple inheritance issues that may
distinguish the C++/python-esque "x.foo()" from CLOS/GOOPS "(foo x)",
or perhaps more accurately they may distinguish something like
"x.foo(a, b)" from "(foo x a b)".  With (foo x a b), x is not nearly
as "privileged" as it is in x.foo(a, b) because instead of just
considering the type of x, you have to consider the types of all of
the arguments, x, a, and b, and each one's class hierarchy, when
trying to determine dispatch.  Of course C++ has operator overloading
and implicit coercions which also complicate reading a call, and
require knowledge of more than just the type of x to determine what's
going on.

> * Using generics might be less readable.
>
> This is indeed a problem. It can be solved by making generic names more
> descriptive, or more commonly to make variable names more descriptive.
> After all, x.output() doesn't tell you much, either.

Yes, though choosing more distinguishing function names does have the
advantage that you can easily do things like

  fgrep '(gtk-close' *.scm

which wouldn't be possible if you're using the more generic names with
disambiguating variable names:

  (close window-foo)
  ...
  (close window-bar)

unless you use the same variable names in every invocation, or stick
to a very regular variable naming pattern.  Perhaps that's not a big
deal, but it might be worth consideration.

> So, I haven't yet decided about naming generics.

And contrary to any impression I may have given above, I haven't
either.  Although it is true that I don't mind more specific names,
and I have usually tended to think of generics more in terms of the
functionality they can provide within a given set of related classes,
I can also understand other people's desire to use the more generic
names, even if it doesn't weigh as heavily with me.

In any case, right now, I'd just like to try to make sure I understand
the relevant issues, and I want to be cautious where public exports
are concerned.

> The debate comes up in the context of g-wrap, a FFI-generating
> library.  It exports some generic functions as part of its API, and
> it's odd to see a library export symbols like `visible?' and
> `add-item!'. All input on this issue is appreciated.

Indeed.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4