Emulating Lift's package structure to customize LiftSession#buildDeferredFunction

[Bhashit Parikh]

Hello folks,

I was planning to do something that might not be considered a good idea. Thought I should get your opinion.

Lift 2.6 (the version we are using) has something called `buildDeferredFunction` that allows us to execute code in different threads as if it's being executed in the request thread We are already using it in some places to deal with Future based code. However, there's one problem, `buildDeferredFunction` only allows creating no-arg functions. So, if you need to pass anything to that deferred function, you have to pass it via closures, with the use of vars that are in scope of the function.

I have thought about creating a version of this that can take a generic argument, to make things cleaner. However, the implementation makes use of certain items that are package-private inside `net.liftweb.http` package.

Here's the question: what do you think about writing my own class that resides in the `net.liftweb.http` package, and implement the function there? The reason I'm even considering this is that Lift 3 already has the function I am suggesting (https://github.com/lift/framework/blob/07c591caa4ece005e0e4dfc58d3c40c9def4f68f/web/webkit/src/main/scala/net/liftweb/http/LiftSession.scala#L1566). So, the package-private code is not going away. If we update to Lift 3, we can just replace our function calls with the ones provided by Lift. If we don't, this would work as expected. Meanwhile, our code can be a bit more clean.

This is really important as I'm planning to use this in a lot of places, and I would prefer avoiding vars altogether.

Thanks for your time,

Bhashit