@specialized and Structural types

0 views
Skip to first unread message

Josh Suereth

unread,
Jul 12, 2009, 1:01:50 PM7/12/09
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

Josh Suereth

unread,
Jul 12, 2009, 1:29:04 PM7/12/09
to scala-i...@listes.epfl.ch, scala...@googlegroups.com
I should mention the desired behavior would be anything that meets the following type A <: Closeable, would use the specialized interface, and anything just meeting A <: { def close() : Unit }, would use the unspecialized interface.  I know there may be other ways to acommplish this, but I still feel @specialized is the way to go.
Reply all
Reply to author
Forward
0 new messages