Constrain abstract class to ensure certain implicits are created for all sub-classes

[bryan hunt]

I want to create a hierarchy of case classes, and I want to add a constrain all the sub-classes to always have an implicit  Reader[this.type ], and Writer[this.type] for the subclass in scope at construction time. 

I've implemented this:

sealed abstract class Operation[ W <: Writes[this.type],                    
R <: Reads[this.type]](val operation: String)(implicit reader: R, writer:W)    
  extends Product {                                                            
                    
}                                                                              
                                                                               
I was wondering, does anyone on the list have an opinion about these kind of constraints?

Is this sort of pattern considered a good or bad pattern to use, perhaps there is a better way to express this sort of constraint?

Disclaimer, my requirements have since changed, so this is purely an academic question.

 

[Alois Cochard]

I found that putting constraints on methods to be more flexible.

If you put it in the class, it means all operation on that type will have the dependencies.

It really depends of the case, I'm not saying your approach is wrong but it's something to keep in mind.

I often had to move such constraints, think well before putting them ;-)

On Dec 13, 2013 2:07 PM, "bryan hunt" <picsol...@gmail.com> wrote: