public interface Locker {
void hold() for myBlock();
}
public class SynchLocker {
private final Object lock;
public SynchLocker(Object lock) { this.lock = lock; }
public void hold() for myBlock() {
synchronized (lock) {
myBlock();
}
}
}
public class LockLocker {
private final Lock lock;
public LockLocker(Lock lock) { this.lock = lock; }
public void hold() for myBlock() {
lock.lock();
try {
myBlock();
} finally {
lock.unlock();
}
}
}
...later...
Locker l = ...take your pick...;
l.hold() {
...do stuff...
}
Let's see you do that efficiently with anonymous inner classes or BGGA.
4 comments:
This kind of thing works with the BGGA prototype today, though the syntax differs slightly. Since Dave's prototype is unavailable to me and it isn't clear what implementation techniques he uses, I'll leave to to Dave to run a performance comparison of his prototype against the BGGA implementation.
You will probably hate this post of mine:
New Control Structures for Java
Since it presents the opposite view of the type of control structure that would be useful to add to Java :)
Dave, thanks for posting your three articles. The reason your approach appeals to me very much more than the other proposals is because your approach does what IMO the others don't - it makes closures accessible and easy to use for "normal programmers". Some of the examples you gave show how a new set of utility closures would rapidly emerge if it was that easy to write, understand and use them. I understand that framework authors may "need" additional complexity, but your proposal seems to solve the vast majority of needs I've come across during "normal" development. I'm replying, because just now I was writing some boilerplate junit code, and thought about how nice it would be if there were some standard assert methods that used the "for block()" capability. Here is a short example I threw together. It may not be quite right, but you get the idea...
public void testCounts() {
assertException(true) {
service.count(0);
}
assertException(false) {
service.count(10);
}
}
public void testIds() {
assertException(true) {
service.findId("a", 10);
}
}
public static void assertException(boolean expectException) for exceptionBlock() {
try {
exceptionBlock();
assertFalse(expectException);
} catch (Exception e) {
assertTrue(expectException);
}
}
Dave, now it's later in the day, and I've come across some more code I'd like to use closures for which I think still falls under the umbrella of "normal" development. However, this time your dumb closures can't help me, since one of the dumb things about them is no return type. Here's my code, but I've added the return type to show my need. I'm not trying to show that your proposal can/can't work with return types - what I'm trying to show is that although your proposal seems to solve a high percentage of my problems, it may not solve enough of them, as a return argument is a a very common need for closures.
public List getRoles(HttpSession session) {
return getAndCache("roles", session) {
return service.getRoles(currentUser);
};
}
public String getUserKey(HttpSession session) {
return getAndCache("userkey", session) {
return service.getUserKey(currentUser);
};
}
public void getAndCache(String key, HttpSession session) for Object search(String key) {
Object found = session.getAttribute(key);
if (found != null) {
return found;
}
found = search(key);
session.setAttribute(key, found);
return found;
}
Post a Comment