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

[Brett Cannon]

On 5/28/07, Mark S. Miller <markm at cs.jhu.edu> wrote:
>
> 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.



That's part of the challenge.  =)  Yes, Python with no verification step
would not work well.  I would have to develop a verification tool to make
sure that code followed some basic rules.  If it doesn't that is where the
refactoring would come in.

Obviously the refactoring would not necessarily be as extensive as possible
in another language, but it should still be doable to some degree.

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.



Once again, part of the challenge.  Chances are some annotations would be
required.  Python 3.0 is adding support for optional arbitrary annotations
on parameters which could be utilized.

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.



True, but it also adds a dependency on a project that I do not have direct
control or interaction.  Plus Joe-E is still under development and thus
fluctuating.  Basing any of this off of my Python work at least puts me in
charge (and thus at fault) of any depdency I would have.

David has also emailed with me on this so he is aware of this idea.


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.


That's basically the scenarios that came to my mind as well.

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.


Yep.

Altogether, whatever language you choose, I think object-capability
> refactorings would be a wonderful research topic. Good luck.
>
>
Thanks!  I will keep the list abreast of whether I go with this topic.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20070528/d1adc2e3/attachment.html