Think about TCP/IP. You have guaranteed delivery of packets (which you don't have with UDP). Completely guaranteed? No. A chopped-off network cable is not something that the protocol can handle. But still very useful.
The TCP/IP is a good example...
To use the same parallel, when I open a TCP connection I am guaranteed that I'm going to get a Socket object (to use Java) I can use. But the platform doesn't guarantee me that its InputStream or OutputStream are going to be valid forever, they might throw IOExceptions, and the socket itself can be in a connected or disconnected status (you're never guaranteed).
You go usually until you don't hit an IOException on the streams (or isConnected() returns true), but then you'll have (somehow) to handle that state change which you don't control...
Wirings between blocks behave in the same way, you go until one of the methods you call doesn't return an exception, or until the wiring is available (err, you can check on that), no more, no less as you would do with a Socket.
Plus (I think) if a component is allowed to programmatically declare its locking to other blocks, I'm absolutely sure that 2 days down the line we're going to have people complaining about:
Them: "I tried to reload that block, but it didn't"
Us: "What does the exception say?"
Them: "Well it says unable to reload because of active lock from MyBlock"
Us: (look at source code of MyBlock and see that someone wrote lock() into it)
If component locking needs to be performed, it needs to be a framework feature unaccessible to components, otherwise it will be abused of.
In the framework, it's easier... At deployment time say to the deployer that the block is "locked" and the framework will never reload it, and all other blocks requiring it, will be "guaranteed" that they won't loose references to the components, even if I simply don't see the point.
Pier
smime.p7s
Description: S/MIME cryptographic signature
