Does anyone know of an OO language where objects have externally explicit namespaces for their protocols? For example, instead of something like “aView.onDropEnter(…)” it might look like “aView.dropping.onEnter(…)“.

CLOS, the Common Lisp Object System. A class method is called a "generic function", and a namespace is called a "package". The syntax for calling a method is

(dropping:onEnter aView ...)

.

So in that function, does it have a giant case statement for every type that might implement the protocol?

It looks like a giant case statement from the outside, I guess. That's not how the code is written. You use

(defclass View ...)

to define a class, you use

(defgeneric onEnter (obj ...) ...)

to define a protocol, and you use

(defmethod onEnter ((obj View) ...) ...)

to implement a protocol for a specific class. Methods are not defined inside the class, they are defined external to the class definition.

A table lookup, which is just one optimization away from a case statement. One key difference: it's extensible. You define new tables with

defgeneric

and new rows in a table with

defmethod

.

It doesn’t make sense to me why it would be organized this way, but then I also don’t understand why the unix file system is organized by function (where installing an app scatters related files across the system instead of keeping them in a single folder).

Classes are not the natural unit of modularity. Often they are, but it's just as common for traditional OOP languages to force you to violate modularity when they insist on grouping all methods for a class inside the same module. Common Lisp provides additional flexibility in how you can organize your code. You can put all the methods for a class into the same source file or package as the class itself, if it makes sense, but you aren't forced to do that.

Go (aka golang) allows methods for anything to be defined anywhere. Haskell typeclasses / instances are somewhat like that. JavaScript too, in that you can use constructors like mixins, by "apply"ing them to any object -- though technically you can apply any "method" to any object at all.

@Dan Cook yeah, I was thinking about implementing this in Javascript. On mixins, don’t they typically shared the class’ method namespace?

This is a pattern that we often use in Pharo and GT.

@Steve Dekorte There are three separate things going on when you talk about methods and namespaces: 1. A method is just a function that takes an extra (invisible) argument called "this", for the object that it is acting on. 2. The conceptual idea of a "method" is that is an actual property (member) of the specific object that it "belongs to". But in most languages, a single function is shared for every instance-object of the same class. So if x and y are both instances of class C, then x.foo(123) and y.foo(456) are really just funny syntax for calling C.foo(x,123) and C.foo(y,456), where x and y are the "this" parameter I described in #1 3. There's the actual container (namespace or parent-object) of the method itself. In #2, the "too" method is contained in class C, although the syntax for calling it makes it look like it is contained in x and y. In most (statically typed) OO languages, these concepts are all munged together: the method is a member of the class and (conceptually) of it's instances, and the fact that "this" is passed as an argument is hidden away by the compiler.

The interface could always have a single method that returns a dictionary of “methods”. I’ve used this approach with Haskell type-classes (which are technically more powerful than interfaces) in cases where it reduced boilerplate (where instead of the instance implementing four simple boilerplate methods it just needs to implement the one)

There's also the question of, what is it you are really trying to do? Research mixins and traits (not what some languages CALL these things, e.g. not in Scala), and you'll find ways that "methods" can be added to classes without actually creating inheritance hierarchies. It's just about grouping methods into one place and then telling the compiler that you want those methods in whichever classes. Look for the scharli paper. DCI also does some interesting things with method-injection, but it's hard to understand and probably better thought of as taking the idea of C# extension methods and applying it to more areas (like a dependent type): int Foo(Bar b, b.(int):string bMethod) { ... b.bMethod(...) } That again, is something that can be handles as a static compiler trick, so that no actual "method" exists at runtime.

@Tudor Girba What does that look like in Smalltalk?

In Smalltalk they are called extension methods 🙂. This is about packaging methods in a separate place then where the class is defined. Traits also happened to have been invented in Smalltalk, and they are about grouping logical behavior.

How about syntax like this: obj.(Other.Namespace.methodForObj)(args) Or: x = methodForObj obj.(x)(args)

@Tudor Girba Can you provide an example of the syntax?

Syntax for what specifically?

For namespace isolated methods that implement a protocol for an object/class/prototype as I described in my question that started this thread.

I was talking about a hypothetical syntax for a new language. The difference is: x.normalMethodOfX(args); x.(expression)(args); Where "expression" is any expression that returns a method. Technically you would also be about to do: x.(x.normalMethodOfX)(args)

I now think I misinterpreted the question. When we want to scope, we create an object that points to the original object.

I use a graph structure where functions may be defined on the relation, eg.

<http://List.to|List.to> String: ...

is semantically same as

String.from List: ...

, you may also organize it by putting an extension of one type in another, eg.

<http://String.List.to|String.List.to> String: ...

. Because of the structured editor, the definitions are visible and may be edited in all relevant places. Because the actual reference is saved in the graph, a later signatures overlap won't break the existing logic, though possibly change the presentation to make it more apparent which relation the signature belongs to.