Closures Cookbook

BGGA Review
	=>演算子が嫌な感じだなぁ…、
	っつうか、レキシカルコンテキストはイラナイのだけどな。

Aggregate Operations
	Closures と、Fluent Interfacesのコンボで、超ｷﾒｪ。
	ライブラリ作るのが大変すぐる。っつうか、コード読むのも、特に読み易いとも思えないんだが…
	これ、どうやってデバッグすんだ？
	特に、lexicalcontext的な話を、ちゃんとデバッグすんの、スゲェ面倒だぞ、きっと。
	スタックにどんだけメモリ食うのかもよく分らん…。
	っつうか、それぞれのOperations部分が、Colosureなら、それぞれヒープに領域とるよねぇ？
	…大丈夫なの？VMが、そこは、最適化するの？
	TS-5515の内容が、非常に参考になるらしい。(寝てたな…ぁぅぁ…)

An API
	Closures使わないケースと使うケースで、どう変わるかねぇ…
	段階を追って、
		メソッド呼び出し
		→独立したクラス
			・戻り値がある時に、何か混ざっちゃうのは、イマイチじゃね？とか。
			・まぁ、デフォルト値次第で、コードの綺麗さは、そこそこ変わるだしなぁ…
		→Multicatchｷﾀｰ!!
		→Rethrowｽｹﾞｰｰｰｰ
		
		→クロージャを使って、APIを書き直してみたり。
			ああ、そうか、Genericsがあるから、Callableで大概良くなるのか。
			でも、俺が好きな、コーディングパターンは、使えないのかな…
			メソッドを複数用意したinterfaceを、ボチボチ呼ぶみたいなアレは…

クロージャと、型引数をExceptionのサブクラスにするコードパターンは相性がいいんだってさ。
interface Block {
	void execute() throws T;
}
こういうのね。

つまり、
interface Executable {
	R execute() throws E;
}

 execute(Executable executor) throws X {
	return executor.execute();
}
まぁ、こうしろ、と言う事か。ｷﾒｪな…

型引数の time() throws X {} なんぞ？
型引数の前置キーワードでthrowsなんて増えるの？

引数の無いクロージャでは、=>演算子を使わない、簡易記法がアリって事らし。

withstreamのサンプルは、穴が開くほど読むべき。
ナンゾ、ｽｺﾞｲ量のコードが、小さく再表現されていた。
クロージャが二重に使われる事で、原型を留めていない様な呼び出しになっていた。
function type notation ???

public class With1 {
    /**
     * A "with" statement that closes your closeable at the end.  Any
     * IOException thrown from the close() method is silently
     * swallowed. Example usage: <pre>
     *    with (InputStream s : new InputStream(...)) {
     *        // code using s
     *    }
     * </pre>
     */
    public static <T extends Closeable,R,throws X> R with(T t, {T==>R throws X} block) throws X {
	try {
	    return block.invoke(t);
	} finally {
	    try {
		t.close();
	    } catch (IOException ex) {
		// ignore exceptions throws from close()
	    }
	}
    }

    static int counter;

    static class MyCloseable implements Closeable {
	final String s;
	MyCloseable(String s) {
	    this.s = s;
	    counter += 1;
	}
	public void close() throws IOException {
	    counter += 2;
	    throw new IOException(); // it will be ignored
	}
    }

    public static void main(String[] args) {
	with (MyCloseable c : new MyCloseable("testing")) {
	    if (c.s != "testing") throw new AssertionError(c.s);
	    if (counter != 1) throw new AssertionError(counter);
	}
	if (counter != 3) throw new AssertionError(counter);
    }
}

eachEntryのサンプルも、何か凄く違和感があるぞ。
forはキーワードなのに、今までと全く違う使い方をしている。
プレゼンで見たのと違うけど、eachのサンプルはこんな感じ。

public class Bloch1 {
    static <T> void each(Collection<T> c, {T=>void} block) {
	for (T t : c) block.invoke(t);
    }

    public static void main(String[] args) {
	List<Integer> li = Arrays.asList(1, 2, 3, 4, 5);
	each(li, { int i => System.out.println(i); });
    }
}

引数の型に、interfaceじゃなくて、メソッドの構造を指定出来るのか。
っつうか、Scalaにも、こんなのあった様なｷｶﾞｽ。
Structural Subtypingとか、そんなんじゃなかったっけか…。

withLockのサンプルは、リエントラントロックが、大きく変わるっつうか、
あれじゃ、syncブロック使えばイイジャン。アフォかｗｗｗｗ