Allow Using or scopeExit in plain functions

[lxohi]

Defer keyword works likes defer in Golang.

It runs the deferred statements in the reversed sequence when current function finished.

[Atry]

What's the difference from Using? lxohi <notifications@github.com> 于 2019年6月1日周六 02:45写道：

…

Defer keyword works likes defer in Golang. It runs the deferred statements in the reversed sequence when current function finished. ------------------------------ You can view, comment on, or merge this pull request online at: #253 Commit Summary - .gitignore: temporarily adds .idea - create keywords-Defer sub-project - create Defer.scala - README.md: add description of Defer keyword File Changes - *M* .gitignore <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-0> (1) - *M* README.md <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-1> (1) - *M* build.sbt <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-2> (13) - *A* keywords-Defer/.js/build.sbt <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-3> (1) - *A* keywords-Defer/.jvm/build.sbt <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-4> (1) - *A* keywords-Defer/build.sbt <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-5> (1) - *A* keywords-Defer/src/main/scala/com/thoughtworks/dsl/keywords/Defer.scala <https://github.com/ThoughtWorksInc/Dsl.scala/pull/253/files#diff-6> (78) Patch Links: - https://github.com/ThoughtWorksInc/Dsl.scala/pull/253.patch - https://github.com/ThoughtWorksInc/Dsl.scala/pull/253.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#253?email_source=notifications&email_token=AAES3OUHF5KRU6IX56IF5D3PYJAM7A5CNFSM4HSAEQ72YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GXCXYFQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAES3OV4KF2JVYKPSVK2NYTPYJAM7ANCNFSM4HSAEQ7Q> .

[lxohi]

Using side:

• Execute the enclosed op immediately.
• The op needs to return AutoCloseable.
• Call the AutoCloseable.close() at the end of current function.

Defer side:

• Execute the enclosed op at the end of current function.
• The op have no need to return anything.

---

We can let Using do the similar thing by adding a implicit conversion like this:

  implicit def toAutoCloseable(op: => Unit): () => AutoCloseable = () => {
    new AutoCloseable {
      override def close(): Unit = op
    }
  }

  private def tryUsingToDefer() = Task {
    !Using(println("1"))
    !Using(println("2"))
    !Using(println("3"))
    println("hello world")
  }

But I don't think it is a good practice because:

• The behavior of that implicit conversion looks a little bit weird.
• This may cause confusion with !Using lines. Adding this implicit conversion will cause the meaning of Using keyword becomes if you put a AutoCloseable in the parentheses it will do A otherwise it will do B.

And by the way the current implementation of Defer is allowed to be used in a normal function block.

[Atry]

I think the implicit conversion is not necessary because Scala 2.12+ (and 2.11 with -Xexperimental) support SAM types. lxohi <notifications@github.com> 于 2019年6月1日周六 22:38写道：

…

Using side: - Execute the enclosed op immediately. - The op needs to return AutoCloseable. - Call the AutoCloseable.close() at the end of current function. Defer side: - Execute the enclosed op at the end of current function. - The op have no need to return anything. ------------------------------ We can let Using do the similar thing by adding a implicit conversion like this: implicit def toAutoCloseable(op: => Unit): () => AutoCloseable = () => { new AutoCloseable { override def close(): Unit = op } } private def tryUsingToDefer() = Task { !Using(println("1")) !Using(println("2")) !Using(println("3")) println("hello world") } But I don't think it is a good practice because: - The behavior of that implicit conversion looks a little bit weird. - This may cause confusion with !Using lines. Adding this implicit conversion will cause the meaning of Using keyword becomes *if you put a AutoCloseable in the parentheses it will do A otherwise it will do B* . And by the way the current implementation of Defer is allowed to be used in a normal function block. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#253?email_source=notifications&email_token=AAES3OTISYEKZPVZO2FWBQ3PYNMDVA5CNFSM4HSAEQ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWXOI7A#issuecomment-498001020>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAES3OQO4D5P6J6LFF2XCM3PYNMDVANCNFSM4HSAEQ7Q> .

[lxohi]

I've tried using SAM types in Scala 2.11 with modified code like this:

  private def tryUsingToDefer() = Task {
    !Using(() => println("1"))
    !Using(() => println("2"))
    !Using(() => println("3"))
    println("hello world")
  }

It just not compile.

I think this is because the parameter type of Using is not AutoCloseable but something have type bounds of AutoCloseable and it makes SAM types doesn't works in this case.

[Atry]

Yes, you are right. We need the following method to enable SAM types in Scala 2.12+.

object Using {
  def apply[R <: AutoCloseable](r: => R)(
      implicit dummyImplicit: DummyImplicit = DummyImplicit.dummyImplicit): Using[R] = new Using(r _)
  def apply(r: => AutoCloseable)(implicit dummyImplicit: DummyImplicit, dummyImplicit2: DummyImplicit) = new Using(() => r)
}

[Atry]

I have some thoughts about the Defer keyword:

1. The current Using implementation is very sophisticated for exception handling. Is it really worth to duplicate the implementation?

2. Should we allow for Defer / Using in plain functions? I worry about possible ambiguity. For example, what is the expected behavior of Using in the following example?

   import akka.http.scaladsl.server.Directives._
   import com.thoughtworks.dsl.keywords.Using
   import java.nio.file.Files
   import java.nio.file.Paths
   import scala.collection.JavaConverters._
   
   def currentDirectoryRoute = {
     pathPrefix("current-directory") {
       get {
         parameters("glob") { glob =>
           val currentDirectory = !Using(Files.newDirectoryStream(Paths.get(""), glob))
           path("file-names") {
             complete(currentDirectory.iterator.asScala.map(_.toString).mkString(","))
           } ~ path("number-of-files") {
             complete(currentDirectory.iterator.asScala.size.toString)
           }
         }
       }
     }
   }

   The above code will close currentDirectory after the route is complete asynchronously at the moment, because Using supports only asynchronous domains. If we allow plain function domains, will currentDirectory be closed before the asynchronous Future is complete?

3. Is it important to support a short syntax for Scala 2.11?

[lxohi]

Thank you for your detailed reply!

About the points metioned above:

1. Not really. With SAM types and if Using can be used in normal functions, I think it's totally fine.

2. The case you pointed out would be a bad case like Scala's return keyword and I believe it is not acceptable.
   But I've tested that Defer keyword was executed when the nearest function finished.

   My test code is:

     def doOp(op: () => Future[Unit]): Unit = {
       import scala.concurrent.duration._
       scala.concurrent.Await.result(op(), 1.minute)
     }
   
     def functionInsideMethod(): Unit = {
       doOp { () =>
         Future {
           !Defer(println(Thread.currentThread().getName, "deferred"))
           println(Thread.currentThread().getName, "function body")
         }
       }
       println(Thread.currentThread().getName, "method body")
     }

   And it prints:

   (default-akka.actor.default-dispatcher-5,function body)
   (default-akka.actor.default-dispatcher-2,deferred)
   (main,method body)
   

   It seems works as expected (like the Golang one).
   I'm not sure is there any corner cases or flaws will let Using/Defer behaves like return in normal functions?

3. By adding the new apply method, SAM types will works in Scala 2.11 :)

[Atry]

Not really. With SAM types and if Using can be used in normal functions, I think it's totally fine.

OK. Since Using covers all the use case of Defer, let's split this PR into two issues:

• Add the Using.scopeExit method #255 for SAM types
• Allow Using or scopeExit in plain functions #253 for plain function domains

[lxohi]

Will modify this branch as soon as #255 was merged (>ω<)

[lxohi]

Hi, because I'm gonna disappear for 4 days, here's just a quick update.

I've modified code which contains plain function support for Using with several test cases.

While scopeExit works fine in function literals like the sample code above, it executed in the wrong scope when passing to a call-by-name param.

Here is a test case will fail due to this issue.

I think this is because call-by-name param does not treated as domain. And this is caused by it's representation is a normal param in the AST not a function.

I'm currently not sure is it doable/a good idea to let the compiler treat call-by-name param as a domain. I will try it when I'm back.

[Atry]

@lxohi We can discuss problem around call-by-name parameters at #22