From: Joel VanderWerf <vjoel@...>
Date: 2001-11-28T17:33:06+09:00
Subject: [ruby-talk:26753] Selector Namespaces and generic functions


Wouldn't multiple dispatch/generic functions solve the problem that
selector namespaces solve?

In Dylan, for example, IIRC, you can put generic functions with the same
name, but different definitions (different member methods), into
different namespaces ("modules"). One of the goals of Dylan, as I
understood, was to avoid the whole public/private/friend nightmare by
decoupling classes from namespaces. The class mechanism provides data
members (slots), inheritance, and a basis for the type system, without
dictating anything about variable binding. The generic function
mechanism controls method selection, also without dictating anything
about variable binding. Orthogonally, the "module" mechanism provides a
semantically neutral way of controlling variable scoping among different
syntactic units. This control extends to generic functions, because
generic functions are referred to through variables.

In concrete terms, given an expression like "foo(1,2,3)", foo gets bound
to some generic function based on the module context. The g.f. then
selects a method based on the argument types (confusingly, this is
sometimes called "dynamic binding"). These two steps in the process are
under the control of separate linguistic mechanisms.

Selector namespaces seem (from the little I've heard) like an extra
layer of complexity to solve a problem originating in the conflation of
classes with namespaces, which is unfortunately the norm in OO
languages.

Actually, the important difference, for resolving method name conflicts,
is not in multiple vs. single dispatch, but in the words "referred to
through variables": instead of selecting methods directly using a
literal symbol, there's an extra level of indirection through a
variable. It's as if every

  obj.foo 1,2,3

were replaced by

  obj.send foo, 1,2,3

where foo has previously been assigned some symbol. Using a variable
instead of a literal lets you scope it as you wish, using scoping
mechanisms that already exist in the language. (Come to think of it, is
the selector namespace idea an attempt to impose scope rules on
literals? That seems pretty strange.)

This is an argument for a serious look at generic functions in Ruby
(with syntactic sugar to avoid breaking code), rather than selector
namespaces. Not only to solve this problem, but because of the elegance
and orthogonality that the g.f. model allows.

--
Joel VanderWerf                          California PATH, UC Berkeley
mailto:vjoel@path.berkeley.edu                     Ph. (510) 231-9446
http://www.path.berkeley.edu                       FAX (510) 231-9512