On Mon, Jun 25, 2007 at 01:07:16PM +0100, Jon Harrop wrote:
...
> I was referring to virtual function dispatch and not the explicit invocation 
> of a particular member.
> 
> Consider this example:
> 
> module A = struct
>   let foo = object method f n = n+1 end
> end;;
> module B = struct
>   let bar = object method f n = n+2 end
> end;;
> 
> let apply o = o#f;;
> 
> apply A.foo 0;;
> apply B.bar 0;;
> 
> If modules imposed separate namespaces then the objects in the modules A and B 
> could not be related, so you could not use them for dispatch in this way 
> (probably a very common use of objects as well).

Actually, treating methods much like types wrt module namespaces is a
very sensible idea.  Without going into further detail of the syntax, in
the above example, module A might declare the method A.f and if module B
intends to implement a method with same semantics as A.f it could be
written as 

    module B = struct
      let bar = object method A.f n = n+2 end
    end;;

and 

    let apply o = o#A.f

would work just the same.  This scheme avoids unintended name clashes,
increases modularity, and, I think, it could result in a more efficient
implementation.

Unfortunately, I'd expect that programmers would react very adversly to
this unexpected additional notational burden.  So there would be a need
to alleviate that burden somehow.

In the literature the above idea is sometimes called "stand-alone
messages".  See Peter Froehlich's work on Lagoona[1] for more
information.

-Chris

[1]: Peter H. Froehlich, Andreas Gal, and Michael Franz. Supporting
Software Composition at the Programming-Language Level. Science of
Computer Programming, Special Issue on New Software Composition
Concepts. Volume 56, Numbers 1-2, Pages 41-57, April 2005.

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F