[e-lang] anyone ever look at refactoring code to use object-capabilities?

[Mark S. Miller]

Brett Cannon wrote:
> So my question is whether anyone knows of any research into refactoring 
> existing code to use object-capabilities (e.g., taking a file object 
> instead of a file path string)?  I am obviously hoping the answer is 
> "no".  =)

For language-based refactorings, as provided by refactoring browsers such as 
Eclipse and IntelliJ IDEA or old Smalltalk-based work, I do believe the answer 
is no. I also agree this direction is interesting and could have some real 
depth to it.

However, I am *very* skeptical about pursuing this direction using Python as a 
base. Firstly, because Python is very far from being an object-granularity 
object-capability language. Your own work at bringing object-capabilities to 
Python, in order to remain Pythonic, gave up early on doing this at the 
granularity of Python objects. Instead, as Tyler Close suggested, you are 
treating an instantiation of a Python interpreter as your unit of protection. 
This is a sound plan, but is, I think, fundamentally in conflict with the 
desire for language-level refactorings.

Secondly, I'm skeptical because of Python's dynamic typing. In most ways, I 
prefer dynamic typing or soft typing to static typing. But for purposes of 
supporting refactoring, I have experienced the *enormous* leverage that IDEA 
gets from exploiting Java's static type information.

Since 1) Eclipse is open source and seems to be catching up, and 2) the Joe-E 
verifier is already packaged as an Eclipse plugin, I suggest that you consider 
changing horses in mid-stream. I think you'll get a lot farther faster by 
building Eclipse plugins to provide refactorings for helping to convert legacy 
Java code so that it passes the Joe-E verifier. The results will also be more 
immediately useful to a larger audience.

Adrian and I have talked a bit about one such possible refactoring, which I 
think should give a flavor of what's possible:

Say we have a legacy Java program that statically accesses the Date class to 
obtain the current time:

     ... new Date().getTime() ...

To turn this into a valid Joe-E program, a capability to access the time must 
be passed in to this location in the code, so that it can be called here:

     ... clock.getTime() ...

How should this program be modified so that this clock is passed in to it? I 
see three natural choices:

* Modify the method containing this line of code to take the clock as another 
parameter. This implies that this object's clients must provide the clock they 
wish this object to use.

* Add a clock instance variable to the containing class, and modify the 
constructors of this class to take an additional clock parameter. This implies 
that the instantiators of this object must provide the clock they wish this 
object to use.

* Turn this class into an inner class, and enclose it in a new outer class 
with a clock instance variable.

In all cases, the program has become more flexible because the clock passed in 
no longer necessarily represents the real clock. If a test harness wishes to 
pass in a faux clock, it would now be easy to do so.

However, each of these three cases is differently flexible. No one of these 
decisions is always better than any of the others. Which to choose between 
depends on the programmer's sense of how to reinterpret the program's intent 
in object-capability terms. Each of these choices will also cause different 
needs for coordinated changes elsewhere in the program.

Altogether, whatever language you choose, I think object-capability 
refactorings would be a wonderful research topic. Good luck.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM