Lambda the Ultimate

Deep in my mind I am rationalistic person and I enjoy solutions with flexibility and elegance. On the other hand, right now I am seeking for clueless solution. A solution that will help people do the right decision with as little understanding as possible. Example:

By default defining method void sayHello() in Java makes it invisible to external API users (which is good, btw.). However as soon as your friend tells you to let him access that method, and you start to seek for the simplest solution, what will you be suggested? Make the method public. Wrong. Well, it works but also exposes you to all the maintenance issues described in my essay.

Having callable around (proposed combination of Java's public final) the like-a-hood a clueless developer did the right choice would be much higher. Hopefully.

Re. "Java allows the expression of basic substitutions, such as your extension doesn't return an int instead of a string, but nothing behavioral" - sounds interesting from rationalistic point of view, however this might be very distinct from problems those millions of Java developers solve daily. Maybe the masses can learn how to describe behaviour as part of their type system in about ten years, but I hope they stop doing the mistakes with public and protected sooner.

I'm unclear how capabilities and access modifiers relate, unless the root issue is that languages with access modifiers rarely support closures.

Closures are one mechanism for building invariants in controlling capabilities; access modifiers are another. If you go beyond object capabilities to general language capabilities (instead of "X can't write or read Y's fields" to "X can't write to field Y"), which I'm starting to think is more in line with how we actually write code, access modifiers are natural mechanisms for securing certain operations.

The second part of your sentence suggests, if OO languages had lambdas, they wouldn't need modifiers. Perhaps, with strenuous encoding, that's true, but what's the point? We need to extend a secure calculus to the full language, and, if we really expect people to write secure code, we should reduce all possible barriers to doing so, including forcing them to write strenuous encodings for notions like "private".

There is a (large) chance current modifiers aren't ideal in terms of language capabilities. However, I'd wager a private instance variable is often closer than "lambda" :) I've been playing with membranes where user policies can control objects or even their fields; this is just a more dynamic, less intrusive, and more adviseable form of "private". What's the right way to go? I don't have a user study to say which.

Doesn't CTM have something interesting to say about this?

I'll admit I haven't gotten nearly as far with that book as I should...

One of the last references in the "public vs. published" talks about Eiffel and its list of types allowed to access a particular attribute. Interesting. I tried to go through some Eiffel tutorial but it does not look like solution to my problem.

First of all it looks like that in Eiffel there is no way to hide something from subclass (at least there is an example that overrides more_sig although defined as {NONE}). The other problem I see is that the default value for access modifier is "everyone" which is comfortable, but dangerous.

What I am looking for is a language that would make:

1. by default nothing is visible to API users
2. method can be marked as callable - then everyone can call it, nobody can redefine it
3. method can be marked as slot - can be called by definer only, subclasses has to implement it
4. method can be marked as callback - subclasses can call it, nobody can redefine it

Of course there can still be private, package private, or similar modifiers. Those are behind the scene and API users don't see them. But forcing each API visible method to choose one and only one from callable, slot or callback, is the holy grail I search for. Eiffel does not feel to help with that. Anyone has better pointers?

It sounds like you mostly just want 'final' to be the default with only abstract methods non-final. Then 'public' and 'private' become your 'callable' and 'callback'. Note that this scheme loses the ability to provide default implementations of methods, since nothing is overrideable. You might consider adding an 'overrideable' keyword for this purpose.

Also note that in moving to this scheme, you're going to lose the standard OO inheritance model, which is the reason the default is non-final. In Eiffel you have pre- and post- conditions which overriding methods must respect. This allows you to reason that a method will work even if the methods it relies on are overridden. Java doesn't have pre- and post- conditions, so its inheritance model seems unprincipled. You can override public methods in ways that break invariants needed by base classes, and the languages provides no support in detecting this.

Sort of true. The mapping to existing Java modifiers is:

• callable = public final
• callback = protected final
• slot = protected abstract

and ban:

• public alone
• protected alone
• public abstract

Although I am suggesting to eliminate half of existing modifiers, I do not think the language would loose any expressive power. There seems to be 1:1 mapping to switch any API to callable/slot/callback style while keeping the original power of the API.

Pre/post conditions look like a good idea, just my dreamed system would have to enforce existence of such checks for every overriddable method. I am trying to prevent developers to accidentally make a method overridable while acting without thinking (usual mode of majority of developers, including me). Rejecting compilation until each overriddable method has at least some pre/post condition would force them to think about meaning of their actions immediately and not after few future releases, when it is too late and one can only suffer with consequences.

Your proposed translation does not have the same properties as the original. Your default implementation idiom requires hooking up every abstract method to its default implementation in every concrete class. Worse is that in the presence of any abstract method, your scheme prevents extending a concrete class. You need two versions of every class to do standard OOP - the version where things aren't yet hooked up that you can extend, and the hooked-up version that you can use. This loses the sub-typing relationship between concrete classes that exists in normal OOP.

I agree with your sentiment that making right things obvious and wrong things awkward is a noble goal. I'm just pointing out potentially unwanted consequences of this idea. My viewpoint is that OOP style per-method inheritance is bad, and my reasoning is pretty much based on the line of thought of our last two posts: You need precise types (tight pre- post- conditions) to make it safe but putting such tight checks everywhere is impractical.