[cap-talk] POLA and Mungi / Iguana style APIs
David Wagner
daw at cs.berkeley.edu
Thu May 19 21:20:54 EDT 2005
Bill Frantz writes:
>This approach allows for the separation of authority between the
>compiler installer, the person who calls the factoryMaker, and the
>compiler user, who calls the compilerFactory. Because the compiler
>instance is discarded after each use, there is no danger that
>capabilities passed on one call may erroneously be used on another call.
Interesting point. Can I try my own version, and can you critique it?
class Compiler {
private File myBillingFile;
Compiler(File f) {
myBillingFile = f;
}
void compile(File src, File obj) {
byte[] objdata = compileString(src.readAll());
obj.write(objdata);
myBillingFile.write(... billing record ...);
}
byte[] compileString(String s) { ... do all the real work ... }
}
class CompilerMaker {
private File myBillingFile;
CompilerMaker(File f) {
myBillingFile = f;
}
Compiler compilerMaker() {
return new Compiler(myBillingFile);
}
}
Does this work as effectively as your proposal?
I'm trying to figure out what the cleanest way to do this in real Java
would be. In particular, I wasn't sure exactly how to implement your
Factory; is the above faithful to what you had in mind? Also, I prefer
to use strictly typed interfaces (no Object[] where a better type is
available).
Note that the above still has a deficiency, because the billing file
object is shared across Compilers, and this provides a channel between
Compiler instances. This might create accidental bugs, or allow malicious
passing of capabilities from one call to another.
My first attempt had compilerMaker() use myBillingFile.clone() rather
than myBillingFile, but this doesn't work in Java, since File.clone() is
protected. Note that this problem also seems to appear in your version.
I think this problem would go away if our objects were stateless (e.g.,
immutable).
More information about the cap-talk
mailing list