wix-incubator / accord

Accord: A sane validation library for Scala
http://wix.github.io/accord/
Other
529 stars 55 forks source link

Validation against dependencies #63

Closed lxwbr closed 8 years ago

lxwbr commented 8 years ago

Validation often requires some dependent data, which is not stored in the object itself. Let me introduce a small example.

case class Foo(id: String)

def validWithUpdate(to: Foo): Validator[Foo] = {
  new Validator[Foo] {
    override def apply(from: Foo): Result = {
      // Check if an update of 'from' to 'to' is valid
    }
  }
}

We are using this kind of pattern quite often. What I am sceptical about is that there is a Validator[Foo] created each time the function validWithUpdate is executed. Which leads me to the question, if this is the best practise in terms of checking against dependencies?

holograph commented 8 years ago

To your question, there's no fundamental limitation that should prevent this from working -- except that where metaprogramming is concerned, until it's proven (= compiles and runs, or at least tests) I tend to err on the side of caution. Note that what is created is an instance of Validator[Foo]; the macro transformation still only happens once.

In short, if this works for you, please note it here so I can put my mind at ease, otherwise let me know what breaks and we'll see about fixing it :-)

lxwbr commented 8 years ago

That does work for us, I was just curious if that would result in some drawbacks in terms of performance. If that is being best practise for such a case though, I am fine with continuing using it.

/cc @aquamatthias

holograph commented 8 years ago

There's obviously some performance penalty for allocating and initializing instances, but that's true of validation in general (allocating results etc.) so it should be another blip on the radar.

Performance in general is a secondary design goal of Accord, I reckon we'll get to it when we actually get complaints from someone who's impacted...