необрезанный расовый Христос

(10x adolfych

duck-typing applied to monads

object closable {
  type Closable = { def close }
  class Autoclose[A <: Closable](c: A){
    def foreach(f: A => Unit) = {
      try { f(c) }finally { c.close }
    }
  }
  implicit def autoClosable[A <: Closable](c: A) = new Autoclose(c)
//...
  case class Connection(name:String) {
    def close = println("closing " + this) 
  }
  case class Statement(c: Connection,q :String){
    def close = println("closing " + this)
    def exec = println("executing " + q + " on " + c)
  }
  def test = for(c <- Connection("conn"); 
		 st <- Statement(c,"select * from table")){
		   st.exec
		 }
}

_navi_, I remember you were talking about something like this

(src 10x Ramzi ben Yahia).

Java: enum is the right place for "abstract factories"

... and/or strategies.

I was pondering where do I stick my two factory strategies, or rather strategy factories - wrote an abstract class and thought about having two final static members, with well-named implementations, when it occurred to me - kaboom, it's an enum:

enum GadgetFactory {
  christmasGadget {
    Gadget build(User user, WeakReference<Something>) {
      ...
   },
  newYearGadget {
    Gadget build(User user, WeakReference<Something>) {
      ...
   };

   abstract Gadget build(User user, WeakReference<Something>);
}

Sure it is obvious. But if it is, why people hardly ever do it this way?

кому нобелевку-то надо давать

Дима говорит - дайте Ассанжу - я согласен.

А вы не пробовали...

В презентацию анимированные гифы вставлять?