a small conundrum

On Mon, Jan 9, 2012 at 9:49 AM, Meredith Gregory
wrote:
> All this can be made to work. But, upon deserialization, this will fail
> because T1Messenger does not inherit from Serializable and does not actually
> have a 0-arg constructor. This is because the Scala compiler will munge it's
> constructor to pass in the surrounding scope.
>
> If we further suppose that T1Messenger cannot (for contextual reasons)
> inherit from Serializable, then we have but one option, to attempt to pass
> the scope just like the Scala compiler does. There's just one little
> problem, we can no longer refer to localT.Expr in the specialization of
> Messenger.
>
> If we assume that T1 is legacy code, i.e. handed to us and it is not an
> option to explode that scope, is there a way to define the specialization of
> Messenger other than effectively enclosing it in a T1Scope-like device?

I can't quite tell if it meets all your constraints, but how about,

trait T1Scope[X,Y,Z] {
type LocalT1 <: T1[X,Y,Z]
def getLocalT1 : LocalT1
val localT1 : LocalT1 = getLocalT1

//class T1Messenger( ) extends Messenger[localT1.Expr[X,Y,Z]]( )
type T1Messenger = Messenger[localT1.Expr[X,Y,Z]]
}

Cheers,

Miles

Sorry -- emacs bindings don't work well with the gmail client -- this got sent before completion...
Dear Scalarazzi,

Consider a couple of case classes tied together inside a parametric trait trait T1[X,Y,Z] {   trait Expr[X,Y,Z]   case class CC1( x : X, y : Y ) extends Expr[X,Y,Z]   case class CC2( y : Y, z : Z ) extends Expr[X,Y,Z] }
Further suppose a class parametric
class Messenger[Msg]( ) {   def send( msg : Msg ) : Unit   def recv( ) : Msg   ...}
Now, is there a way to specialize Messenger to be parametric in Expr?
One obvious solution is
trait T1Scope[X,Y,Z] {   type LocalT1 <: T1[X,Y,Z]    def getLocalT1 : LocalT1   val localT1 : LocalT1 = getLocalT1
   class T1Messenger( ) extends Messenger[localT1.Expr[X,Y,Z]]( )}
But, now consider the following elaboration
trait T2Scope[X,Y,Z] extends T1Scope[X,Y,Z] {    class T2Messenger( storage : SomePersistentStore ) extends T1Messenger( ) with Serializable {       def flyInTheOintment( kkey : String ) : Unit = {             reset {                shift {                   ( k : Unit => Unit @suspendable ) => {                        storage.store( kkey, serializer.serialize( k ) )                    }                }            }       }   }}
All this can be made to work. But, upon deserialization, this will fail because T1Messenger does not inherit from Serializable and does not actually have a 0-arg constructor. This is because the Scala compiler will munge it's constructor to pass in the surrounding scope.
If we further suppose that T1Messenger cannot (for contextual reasons) inherit from Serializable, then we have but one option, to attempt to pass the scope just like the Scala compiler does. There's just one little problem, we can no longer refer to localT.Expr in the specialization of Messenger. 
If we assume that T1 is legacy code, i.e. handed to us and it is not an option to explode that scope, is there a way to define the specialization of Messenger other than effectively enclosing it in a T1Scope-like device?
Best wishes,
--greg
On Mon, Jan 9, 2012 at 1:19 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Dear Scalarazzi,
Consider a couple of case classes tied together inside a parametric trait
trait T1[X,Y,Z] {
   case class CC1( x : X, y : Y ) }
Best wishes,
--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com