Stefano Mazzocchi wrote:
On Monday, Sep 29, 2003, at 20:42 Europe/Rome, Upayavira wrote:
Geoff Howard wrote:As I understand it, this is a matter of block librarian implementation, and isn't a build consideration. Blocks depend on other blocks only through declared component resolution and pipeline based resource exposure. So, compiling a block (and therefore its build) doesn't need these other implementations to be resolved. Only the deploy step needs them present and that's the domain of the block librarian and block deploy tool isn't it?
If block A defines a component with a method getBlah, and block B has a component that uses that method, how do you compile block B without having the source for block A available? Surely there is _some_ compile time consideration to be made?
The behavioral interfaces of the avalon components are the only things the compiler needs, thanks to complete polymorphic design.
So you won't be able to include and share arbitrary components between blocks? i.e. components that have arbitrary interfaces? They'll all have to follow interfaces that already exist within Cocoon? Or am I missing something?
No, you can include and expose arbitrary components. The interfaces he's referring to are the abstracted api interface of the component independant of its implementation but they are totally up to the author of the component.
So, if you are the author of block A you create
public interface MyInterface {
public void doSomethingInteresting();
}public class MyComponent implements MyInterface {
...
}and only MyInterface.class is needed to _compile_ block B, not the whole cob file or even MyComponent.class
So, until the interface changes, no need to update dependencies in cvs.
Now, the big question outstanding in my mind is what happens if you have:
public interface InterestingInterface {
public BlockSpecificDataStructure doSomethingElse();
}We've said that direct classloading from the block is prohibited but here you need the definition of BlockSpecificDataStructure. So how do you permit one and deny the other? And does this get you into odd ClassCastExceptions where the same class from different classloaders are not recognized as identical?
Geoff
