Separate ObservableBuffer.Replace change

[scalasolist]

Just expanding suggestion that was mentioned in closed topic: #169 (comment)

trait ContentChange extends Change
trait Add extends ContentChange
trait Remove extends ContentChange
class Replace extends Add with Remove

Why do you need a new type of change event? There are use cases when you need to keep a complex structure on sync with changes made in a ObservableBuffer. There should be two cases: resource consuming in case of changing the buffer structure (add, remove, reorder) and resource cheap case when only values in the buffer changes and only part of the complex structure need to be recomputed

I use a simple array for example. It is really painful to rearrange it, very cheap to replace its elements. If you have a use case where editing values occurs much more frequent than adding or removing elements, it would suit well.

class ProxyBuffer[T](val host : ObservableBuffer[T])(implicit tag : ClassTag[T]) {
  protected var proxy : Array[T] = Array( host : _* )

  protected def sync() : Unit = {
    proxy = Array()
    proxy ++= host
  }

  protected def sync(from : Int, to : Int) : Unit = {
    for (i <- from until to)
      proxy(i) = host(i)
  }

  host.onChange( (obs, chs) => {
    object StructureChanged extends Exception()
    try {
      for (change <- chs)
        change match {
          //case ObservableBuffer.Replace(from, to) => sync(from,to)
          case ObservableBuffer.Add(_,_) => throw StructureChanged
          case ObservableBuffer.Remove(_,_) => throw StructureChanged
          case ObservableBuffer.Reorder(_,_,_) => throw StructureChanged
          case ObservableBuffer.Update(from, to) => sync(from,to)
        }
    } catch {
      case StructureChanged => this.sync()
    }
  } )
}

The commented string shows what I'd like to get.

Why should the add, remove, replace changes be not mutually exclusive. There are still many use cases that require the listener to react only on elements appearing or disappearing in the ObservableBuffer.

change match {
  case ObservableBuffer.Add(_,elems) => elems.foreach( e => provider.register(e) )
  case ObservableBuffer.Remove(_,elems) => elems.foreach(e => provider.deregister(e) )
}

Such use cases are more common then the first mentioned. So they should be simpler to write handler to. Moreover the javafx documentation (which is used by me and probably other scalafx users since there is no separate scalafx documentation) states that the replace change is not mutual exclusive with the add and the remove. And this concept is used in the javafx examples. So it would be nice to keep compatibility with javafx examples and old scalafx applications that would miss the add events if they would be consumed by the replace events.