More on multimethods
Ran across Millstein and Chamber's 2002 paper, Modular Statically Typed Multimethods. Based on Chambers' work on Cecil, it presents a much cleaner, logically-consistent way of doing multimethods.
As a result, I am far less suspicious of them than I was a few days ago.
<aside>
Computer science papers have an amazing knack for being opaque. Perhaps that's why good programming books are so prized. The entire meat of this paper could have been covered in a couple pages of source examples and discussion, with an appendix for the formal definitions — as is, it's 47 pages long.
(Literally. I use "forty-seven" like the Hebrew scriptures use 40, as an unspecified but ludicrous length, like "enter your forty-seven digit extension after the beep." This paper, however, is actually 47 pages long.)
But of course, a nicely tech-written summary wouldn't have made ECOOP.
Anyway.
</aside>
Their system, System E, still strikes me as iffy in the face of runtime-loaded code. Java's ability to load and unload code on the fly is the source of a lot of its power — it's the feature that allows application servers and really-well-integrated IDEs — and I intend to preserve it in Mongoose.
However, I think System E can be easily adapted for runtime loading. It does some link-time typechecking to verify consistency, and if linking happens to occur during execution, no biggie.
It still bothers me that calling a function
System E defines inter-module restrictions that could be used to control some of this; the rest could be left to the language security model, perhaps marking some functions as non-overrideable (Java's
Alternatively, if the language can partition loaded code off in its own little sandbox (a la Java's pending Partition feature), perhaps function overloads could be prevented at the partition level.
I'm tinkering on a design for Mongoose that leverages these ideas. More to come.
As a result, I am far less suspicious of them than I was a few days ago.
<aside>
Computer science papers have an amazing knack for being opaque. Perhaps that's why good programming books are so prized. The entire meat of this paper could have been covered in a couple pages of source examples and discussion, with an appendix for the formal definitions — as is, it's 47 pages long.
(Literally. I use "forty-seven" like the Hebrew scriptures use 40, as an unspecified but ludicrous length, like "enter your forty-seven digit extension after the beep." This paper, however, is actually 47 pages long.)
But of course, a nicely tech-written summary wouldn't have made ECOOP.
Anyway.
</aside>
Their system, System E, still strikes me as iffy in the face of runtime-loaded code. Java's ability to load and unload code on the fly is the source of a lot of its power — it's the feature that allows application servers and really-well-integrated IDEs — and I intend to preserve it in Mongoose.
However, I think System E can be easily adapted for runtime loading. It does some link-time typechecking to verify consistency, and if linking happens to occur during execution, no biggie.
It still bothers me that calling a function
foo might get me two different code paths before and after loading a module, depending on the (surprise) types of the arguments. This is mostly a security issue for me: if a module is able to stub-out some hasPrivilegedAccess function on load, all hell breaks loose.System E defines inter-module restrictions that could be used to control some of this; the rest could be left to the language security model, perhaps marking some functions as non-overrideable (Java's
final).Alternatively, if the language can partition loaded code off in its own little sandbox (a la Java's pending Partition feature), perhaps function overloads could be prevented at the partition level.
I'm tinkering on a design for Mongoose that leverages these ideas. More to come.
posted by Cliff L. Biffle at
11:06 PM
0 Comments:
Post a Comment
<< Home