pattern.scala

// edit : haskell must also have this problem but how does it solve it? 

sealed trait Blah

// the names aren't important, just that Thing1-3 are all types of Blah and contain dif info (A/C/Z/etc)
case class Thing1(piece: A, otherPiece: C) extends Blah
case class Thing2(hierarchy: Z) extends Blah 
case class Thing3(thinger: F) extends Blah 
case cbject DefaultThing extends Blah 

// some time later, these have all been jammed into a single list 
// and I have to pattern match to get out be it in a fold, or a map, or whatever 
// in this example it's a List A = > List B so a map, but it could have been List A => C as in a fold 

// what are my options for putting this together differently? 

def doStuff(inputs: List[Blah]): List[SomethingElse] {
  
  // having to always remember to pattern match whenever I'm in a container is annoying
  // can I map some function that exists for all types of Blah (typeclass apporach? what would this look like) to make this 
  // cleaner?
  inputs.map {
    case thing1: Thing1 => 
    case thing2: Thing2 => ...
  }
}

// other considerations
//say I have some ADT 
// sealed trait A 
// with types B and C.  Maybe B represents the ability of grouping data by a city 
// and C represents the ability of grouping data by a salary band 
// do you make a type D for NoGrouping? 
// considerations: you know this ends up in a list 
// if you are say mapping a list of [B,C] with some input Data and you want to get back a list of groupings, 
// then not make a type D since the empty List counts as the "no grouping" case?  so then your list of positions 
//  is either List[Bpositons, Cpositions] or List() in the case where are no positions and some far off place you have an 
// isDefined check to catch the tmpy case?

// or do you make some type (a sum type, pun) where you either have No Grouping OR a List of groupings 
// and propagate this such as mapping the no grouping builds the EmptyPositions or something, 
// such that when you get to some far off place you've at least named the empty case rather than having this weird check?

// googling around for what to do instead
// I see Spiviek saying this is a problem 
// https://stackoverflow.com/a/25334369/3230177 here 
// "As a wildcard, a third potential disadvantage to this sort of type specificity is it encourages (or rather, allows)
//   a more "object-oriented" style where you put case-specific functions on the individual ADT types. I think there is 
//   very little question that mixing your metaphors (case classes vs subtype polymorphism) in this way is a recipe for
//    bad."
//  ^-- but I see this mixing all day long.  In the above example, just give those case classes some behavior.