Josh Suereth
unread,Jul 12, 2009, 1:01:50 PM7/12/09Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to scala-i...@listes.epfl.ch, scala...@googlegroups.com
Hey All,
I wanted to cover a use case which I thing might deserve some attention from the @specialized implementations. I'd like to do the following.
Currently I have structural typing in an Automated Resource Management library (specifically Scalax). The "generic" ManagedResource constructor looks as follows:
object ManagedResource {
/** Creates a ManagedResource for any type with a close method. Note that
* the opener argument is evaluated on demand, possibly more than once, so
* it must contain the code that actually acquires the resource. Clients
* are encouraged to write specialized methods to instantiate
* ManagedResources rather than relying on ad-hoc usage of this method. */
def apply[A <: { def close() : Unit }](opener : => A) =
new UntranslatedManagedResource[A] {
def unsafeOpen() = opener
def unsafeClose(r : A) = r.close()
}
}
While the A <: { def close() : Unit } is a very flexible type annotation for users of the library, I'd like to improve speed for the case where you're using something with a specific Closeable interface (either a scala one, or java.io.Closeable). You notice the nice documentation warning abotu specializing this interface by hand. I was wondering if the following is possible:
trait Closeable {
def close() : Unit
}
object ManagedResource {
def apply[A <: { def close() : Unit } @Specialized(scalax.resource.Closeable, java.io.Closeable](opener : => A) =
new UntranslatedManagedResource[A] {
def unsafeOpen() = opener
def unsafeClose(r : A) = r.close()
}
}
If this isn't in the design mix, I was wondering if maybe perhaps it should be a use case.
Thanks
- Josh