right-biasing Either

[Jason Zaugg]

(A follow-up from ticket SI-5793. [1])

Apologies in advance to any left-handers out there.

I propose (not that I'm the first) to right-bias Either. Concretely,
this means we would add map/flatMap etc directly to Either, rather
than going through RightProjection. RightProjection could probably
deprecated.

Is there any previous discussion on this? Any arguments against?

-jason

[1] https://issues.scala-lang.org/browse/SI-5793

[Kevin Wright]

Tallying up those of us in Zeebox who would have directly benefitted from this, count me for +12 votes in favour.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[√iktor Ҡlang]

Count me in for +1

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Jon-Anders Teigen]

-1

The Unbiased Either is perfect for representing one of two values -
either the right or the left - without implying that one of them is
more "correct" than the other.

If there is bias towards right or left there is usually a good name
for that bias. For example Validation from Scalaz, and ParseResult
from the parser combinators. They are often fixed in one of the
parameters too, like Future.

That said, I do like the idea of a general right biased either, but I
really really don't want to sacrifice the unbiased one in in the
process.

/j

On May 14, 10:49 am, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
> Count me in for +1
>

> On Mon, May 14, 2012 at 9:36 AM, Kevin Wright <kev.lee.wri...@gmail.com>wrote:
>
>
>
>
>
>
>
>
>
> > Tallying up those of us in Zeebox who would have directly benefitted from
> > this, count me for +12 votes in favour.
>
> > On 14 May 2012 08:08, Jason Zaugg <jza...@gmail.com> wrote:
>
> >> (A follow-up from ticket SI-5793. [1])
>
> >> Apologies in advance to any left-handers out there.
>
> >> I propose (not that I'm the first) to right-bias Either. Concretely,
> >> this means we would add map/flatMap etc directly to Either, rather
> >> than going through RightProjection. RightProjection could probably
> >> deprecated.
>
> >> Is there any previous discussion on this? Any arguments against?
>
> >> -jason
>
> >> [1]https://issues.scala-lang.org/browse/SI-5793
>
> > --
> > Kevin Wright

> > mail: kevin.wri...@scalatechnology.com
> > gtalk / msn : kev.lee.wri...@gmail.com

> > quora:http://www.quora.com/Kevin-Wright
> > google+:http://gplus.to/thecoda

> > <kev.lee.wri...@gmail.com>

> > twitter: @thecoda
> > vibe / skype: kev.lee.wright
> > steam: kev_lee_wright
>
> > "My point today is that, if we wish to count lines of code, we should not
> > regard them as "lines produced" but as "lines spent": the current
> > conventional wisdom is so foolish as to book that count on the wrong side
> > of the ledger" ~ Dijkstra
>
> --
> Viktor Klang
>
> Akka Tech Lead

> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang

[Kevin Wright]

Straight from the scaladoc:

"Represents a value of one of two possible types (a disjoint union.) Instances of Either are either an instance of Left or Right.

A common use of Either is as an alternative to Option for dealing with possible missing values. In this usage, scala.None is replaced with a Left which can contain useful information. Right takes the place of Some. Convention dictates that Left is used for failure and Right is used for success."

So we've already been advocating for quite some time that "right" is right, and that Either would typically be used *as though* it were biased.

I personally take the line that the established ScalaDoc is correct, and that the code should be modified to match it.  If "Right" is to take the place of "Some", then let's have the ability to map over it in exactly the same way - it would do wonders for my for-comprehensions!

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

[√iktor Ҡlang]

On Mon, May 14, 2012 at 11:19 AM, Jon-Anders Teigen <jte...@gmail.com> wrote:

-1

The Unbiased Either is perfect for representing one of two values -
either the right or the left - without implying that one of them is
more "correct" than the other.

If there is bias towards right or left there is usually a good name
for that bias. For example Validation from Scalaz, and ParseResult
from the parser combinators. They are often fixed in one of the
parameters too, like Future.

That said, I do like the idea of a general right biased either, but I
really really don't want to sacrifice the unbiased one in in the
process.

We're just talking about _adding_ methods, so if you want to continue using it as unbiased then that'd still be possible. I'm not all that for deprecating the rightPRojection since that'd give me the feeling of asymmetry, which just feels wrong to me.

--

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Daniel Sobral]

On Mon, May 14, 2012 at 6:38 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> Straight from the scaladoc:
>
> "Represents a value of one of two possible types (a disjoint union.)
> Instances of Either are either an instance of Left or Right.
>
> A common use of Either is as an alternative to Option for dealing with
> possible missing values. In this usage, scala.None is replaced with a Left
> which can contain useful information. Right takes the place of Some.
> Convention dictates that Left is used for failure and Right is used for
> success."
>
>
> So we've already been advocating for quite some time that "right" is right,
> and that Either would typically be used *as though* it were biased.

Err, no. It says right before "A common use", so this does not
represent how Either should be used, but an example of how it is often
used. It does not preclude at all using Either as a union-replacement.

--
Daniel C. Sobral

I travel to the future all the time.

[Kevin Wright]

Out of curiosity... How many examples can we come up with of Option being used in the wild, in a completely symmetric fashion that would suffer if it were to be biased?

Because I (for one) am *really* keen to just go the whole hog and have both Option and Either implement FilterMonadic, but wouldn't like to see this sort of thing cause a problem if there were obvious counter-examples in production somewhere!

[Runar Bjarnason]

Yes, please.

[Heiko Seeberger]

On May 14, 2012, at 9:08 AM, Jason Zaugg wrote:

> (A follow-up from ticket SI-5793. [1])
>
> Apologies in advance to any left-handers out there.
>
> I propose (not that I'm the first) to right-bias Either. Concretely,
> this means we would add map/flatMap etc directly to Either, rather
> than going through RightProjection. RightProjection could probably
> deprecated.
>
> Is there any previous discussion on this? Any arguments against?

No arguments against. Vice versa, I frequently have the use case of treating Right as the right case and Left as the error case. Hence I always have to use Scalaz, which is not too bad per se and provides additional value (like applicative functors), but why not add this feature to the standard library?

Heiko

[Chris Hodapp]

Why right-bias a class with an unbiased name like "Either" when the potential for creating a new class that doesn't have the wrong name exists?

[Rex Kerr]

-1

I prefer unbiased Either.  If we wanted to provide an implicit conversion to Option (via right projection) I doubt I'd mind, but Either can be used (and I do use it) to store two alternative things without bias.  Adding bias will create a strong pressure for asymmetric code even though the conditions are symmetric.

If there is not an implicit conversion, I'd prefer a third class that was biased.  If we wanted to avoid stepping on the Scalaz names, "Excused" might work.

  --Rex

[Kevin Wright]

In a word... confusion!

Why create two types that do almost exactly the same thing, but one of them does it with a bit less ceremony in the overwhelmingly most common use-case?

I'm all for giving developers choice, but this seems to be taking it perhaps too far.  How can we possibly justify the maintenance burden of keeping two Either's around?  Not to mention the cognitive burden of having to explain the intricacies to new Scala users, especially those transitioning from Java.  I can just see it now:

"You should really use Maybe, not Either.  I know all the books in print right now don't even mention it yet, but you'll just have to trust me until you come to understand for-comprehensions better, and monads"

...Followed by the inevitable web search for monads and (more often than not) the resulting confusion followed by claims of Scala being too complicated and "academic". Then followed by the further inevitable repair of any damage so caused.

Even now, I still find myself fielding accusations of "but wasn't App deprecated?" - and that was a far simpler scenario, where we had two alternatives but one was deprecated.

If we're not keeping two variants around, then we should stick with the one we have, but fix it up to just do the Right Thing(tm).  It'll save a great deal of pain later!

[Kevin Wright]

Is this-use case not better handled by a sealed marker trait and two subclasses for the symmetric alternatives?

[√iktor Ҡlang]

... and change option to:

type Option[_] => Either[Unit,_]

;-)

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Erik Osheim]

On Mon, May 14, 2012 at 05:14:23PM -0400, Rex Kerr wrote:
> If there is not an implicit conversion, I'd prefer a third class that was
> biased. If we wanted to avoid stepping on the Scalaz names, "Excused"
> might work.

As a thought experiment, would you be OK with making Either biased as
Jason proposed, but introducing a new type that is unbiased? E.g.

sealed trait OneOf2[+A, +B]
sealed trait OneOf3[+A, +B, C+]
...
sealed trait OneOf22[...]

case class Item1[A](a:A) extends OneOf2[A, Nothing] with OneOf3[A, Nothing, Nothing] ...
case class Item2[B](b:B) extends OneOf2[Nothing, B] with OneOf3[Nothing, B, Nothing] ...
case class Item3[C](c:C) extends OneOf3[Nothing, Nothing, C] ...
case class Item4[D](d:D) extends OneOf4[Nothing, Nothing, Nothing, D] ...
...
case class Item22[A, B, ... V](a:A, b:B, ... v:V) extends OneOf22[..., V]

I tend to use sealed traits to handle this kind of symmetric
disjunction. The thing that's nice about something like OneOf versus
Either is that the name generalizes well to 21 variants you might want.

That said, I tend to use sealed traits instead of Either, so I'm mostly
bikeshedding. But I think that having a balanced OneOfN might be a bit
nicer than Either, since the pattern's a bit more general.

-- Erik

[Kevin Wright]

I already do something like that anyway :)

Spurned by jealousy for node.js, my latest project is written in a completely asynchronous style.  For me, "Either" is named "Future", and it's nicely right balanced...

In fact, it's *so* asynchronous that it may even get written one of these days!

[Alec Zorab]

I heard someone already wrote it and called it Akka...

[missingfaktor]

On Tue, May 15, 2012 at 2:44 AM, Rex Kerr <ich...@gmail.com> wrote:

-1

I prefer unbiased Either.  If we wanted to provide an implicit conversion to Option (via right projection) I doubt I'd mind, but Either can be used (and I do use it) to store two alternative things without bias.  Adding bias will create a strong pressure for asymmetric code even though the conditions are symmetric.

If there is not an implicit conversion, I'd prefer a third class that was biased.  If we wanted to avoid stepping on the Scalaz names, "Excused" might work.

  --Rex

+1, except I think { Attempt, Success, Failure } would be better names to go for. (I think Validation is not a particularly good name as it describes only one case such a data type can be used for.)

On Mon, May 14, 2012 at 3:08 AM, Jason Zaugg <jza...@gmail.com> wrote:

(A follow-up from ticket SI-5793. [1])

Apologies in advance to any left-handers out there.

I propose (not that I'm the first) to right-bias Either. Concretely,
this means we would add map/flatMap etc directly to Either, rather
than going through RightProjection. RightProjection could probably
deprecated.

Is there any previous discussion on this? Any arguments against?

-jason

[1] https://issues.scala-lang.org/browse/SI-5793

--

Cheers,

missingfaktor.

[Rex Kerr]

Of course it's not better to use a sealed marker trait.  That's considerably more boilerplate.  In some cases it's worth it to not have to deal with the left/right thing, but only _some_.  Of course I can always write my own Either.  (And I can write my own right-biased Either, also.)

What about just adding an "opt" method to Either that is right-biased and gives you an option?  This is a lot more compact than .right.toOption.

Or maybe I would like to see which methods exactly are being proposed for addition.  There are
  foreach(f: B=>Unit): Unit
  // right.foreach

  map[D](f: B=>D): Either[A,D]
  // right.map

  flatMap[C>:A,D](f: B=>Either[C,D]): Either[C,D]
  // right.flatMap

  mapOr[C>:A,D](wrong: => C)(f: B => Option[D]): Either[C,D]
  // right.flatMap(x => f(x).toRight(wrong))

  collectOr[C>:A,D](wrong: => C)(pf: PartialFunction[B,D]): Either[C,D]
  // right.flatMap(x => pf.lift.apply(x).toRight(wrong))

  rescue[D>:B](f: A => Option[D]): Either[A,D]
  // fold(l => f(l).map(o => Right(o)).getOrElse(Left(l)), r => Right(r))
   
  reject[C>:A](f: B => Option[C]): Either[C,B]
  // fold(l => Left(l), r => f(r).map(o => Left(o)).getOrElse(Right(r)))

  toOption: Option[B]
  // right.toOption

which all seem highly useful to me.  I'd actually be more interested in the change if we were going to add a really robust set of methods so that Either would be as generally powerful as Option (without having to left/right to get something usable).  (Might be good to add iterator/toList also.)  Bias with only minimal utility is much less interesting.

  --Rex

[Kevin Wright]

Right-bias is not about being able to quickly convert to an Option, it's about being able to chain a sequence of operations, each of which takes the right output of the previous operation and yields an either.

Most especially, it's about being able to do so in the context of a for-comprehension.

Implicit conversion to Option wouldn't help here, it would actually harm.  Comprehensions like this should output either the Right result of the processing sequence, or the Left failure from whichever step ran into problems.  If converted to an Option then we'd be forced to either throw errors as exceptions, or to simply discard failures and simply know that something didn't work as expected - neither choice is especially appealing.

Deprecating Either in favour of a different name makes sense, but it then leaves us with a lot of source to be updated, and a lot of existing documentation (books, articles, etc.) that is no longer valid.

[Tony Morris]

Some history. I wrote scala.Either.

Originally, it was Right-biased. A peer convinced me to remove the bias,
partly because abstracting on the type constructor was not something
that regular scala libraries do, and unlike Haskell, Scala type
constructors can be rearranged on the fly, therefore, there appeared to
be no real advantage. I agreed.

I have since regretted it, given that there are other advantages than
those I dismissed at the time. I vote +1 for this proposal.

--
Tony Morris
http://tmorris.net/

[Rex Kerr]

On Mon, May 14, 2012 at 6:23 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

Right-bias is not about being able to quickly convert to an Option, it's about being able to chain a sequence of operations, each of which takes the right output of the previous operation and yields an either.

Most especially, it's about being able to do so in the context of a for-comprehension.

Fair enough.  But if this is the only thing it can do, I'm not sure it's worth it.  You can do the chaining clumsily (i.e. by putting in a .right as a separator between all your normal calls) everywhere except for comprehensions.  So the idea is that a for-comprehension is worth more than the symmetry.  Maybe.

I think the maybe could be turned into a clear win _if_ extra functionality was provided for the most common use cases, and these involve _not just_ flatMap but the other methods I wrote down below.  Namely:

  (1) If my option (or partial function) fails, I want to put an error in Left
  (2) I want to try to recover from some fraction of the Left cases
  (3) I want to throw away some fraction of the Right cases

If something like this is included also, then I'd agree: we've gained something important.  Simply not having to write out the desugared version of the for loop seems like not much of a win to me given that things like
  Either[Either[IllegalArgumentException,IOException], DataSet]
  Either[IllegalArgumentException, Either[BigInt, Formula]]
will no longer make so much sense.

  --Rex

[Lee Mighdoll]

Most especially, it's about being able to do so in the context of a for-comprehension.

Fair enough.  But if this is the only thing it can do, I'm not sure it's worth it.  

 

+1 for for comprehensions.  They enable a code style that's very clear, and really a nice scala selling point when compared to more mainstream languages.  Let's make for comprehensions shine.  

Note that in for comprehensions the existing Either implementation isn't just extra boilerplate to pick a projection on every line.  Definitions don't work.  

As is, I don't think we can recommend using Either to our teams today, certainly not without bunch of caveats and extra explanation.  That argues we ought fix the existing Either, rather than pick a new class.

And I don't think there'd be much cost to the change.  There'd be little mental shift required of the community if the right side of the Either gets blessed.  I'll guess that the vast majority of existing Either users mentally associate Either with the asymmetric use case already (even as we appreciate the nifty symmetry of the existing design).  Think Either, and I bet most think of a tool for dealing with Left(error) and Right(result).  

+1 for biasing Either in 2.10

[Jason Zaugg]

A new player has entered the arena:

https://github.com/scala/scala/blob/master/src/library/scala/util/Try.scala

-jason

[missingfaktor]

That looks a lot like the one from twitter-util. 

https://github.com/twitter/util/blob/master/util-core/src/main/scala/com/twitter/util/Try.scala 

--

Cheers,

missingfaktor.

[Heather Miller]

This comes from discussions with Twitter several months ago during the evolution of the Futures library. Apparently, Twitter heavily uses Try internally, they have a couple of years of experience with it and attest that it results in much simpler, more readable, and less accident-prone (wrt swapping Left and Right) code. As a result, on their end, they require that Futures use Try over Either. So, during a few discussions here, Martin was in favor of introducing Try to the stdlib and using them with the Futures library, as, arguably, Twitter's Futures library has to be the most battle-tested Scala Futures library out there.

However, since the Akka folks solidified their API before scala.concurrent was finalized, that decision was reversed. So, the signatures in scala.concurrent still involve Either, but there exists an extractor which allow one to use Trys as well.

So, usage like: 

val f = future{0}

f onComplete {

  case Success(v) => println(v)

  case Failure(e) => println("Exception")

}

is still possible.

Since it's a small step towards unifying more Futures libraries (as Twitter is an important user, likewise with a lot of valuable experience), it's been agreed for a bit that Try will likely stick around. 

Though, a bottom-line here is, of course, that Try can be used outside of the context of Futures.

-- 

Heather Miller

Doctoral Assistant

EPFL, IC, LAMP

http://people.epfl.ch/heather.miller

[Heather Miller]

To copy/paste a tidbit of motivation here:

We introduced `Try` a while back along with SIP-14 (Futures). `Try` is analogous to `Either` with the exception that it's success-biased. That is, Either is symmetric, it has two type parameters that are wrapped (symmetrically) in either `Left` or `Right`. In general, by convention, `Either` can be used to represent a "successful" or a "failed" result, by representing some generic type in its right projection, and a subtype of Throwable in its left projection. However, this is by convention only, one can of course swap these projections (whether accidentally or purposefully) or one can represent two successful values in each projection if they so desire.

`Try`, on the other hand, is parameterized only on one type, with this success/failure use case in mind. That is, the successful case is wrapped in `Success` (parameterized on T) while the failed case is a `Throwable` wrapped in `Failure`.

`Try` comes from Twitter, who use it frequently in their codebase (see twitter/util on github), and who have found that it results in more readable and less error-prone code for this success/failure use case of `Either`.

-- 

Heather Miller

Doctoral Assistant

EPFL, IC, LAMP

http://people.epfl.ch/heather.miller

[missingfaktor]

Why is Failure specialized on Throwable? It could/should be type-parametrized IMO. Throwable seems like an unnecessary restriction.

--

Cheers,

missingfaktor.

[Kevin Wright]

I want to have my cake and eat it too!  A right-biased disjoint union in which I can parameterise the type of BOTH sides.

Consider this example:

https://gist.github.com/1262988

My rejection is NOT a Throwable, it doesn't incur the cost of building the stack trace for an exception, and it additionally carries the value that caused the failure to occur.

Yes, I know that I were to use Try I could create my own Throwable/Exception type and have it carry whatever other values I care for.  But that's just removing ceremony from one place only to hand it back in another, likely sacrificing performance in the process.

[Rob Dickens]

How about doing the following:

* leave Either as it is, since the name doesn't imply any bias
(although Right certainly does), and it looks like changing it would
only buy you definitions in for-comprehensions (and not having to add
.right)

* introduce a completely new class, Checked, having OK and KO as the
type constructors

* include support for combining Checked values in both a fail-fast and
fail-slow manner, including applicative-functor support (<*>
operator), similar to that which I describe here:

http://robsscala.blogspot.co.uk/2012/05/validating-multiple-values-at-once.html

Rob

[Gary Pampara]

Fixing a problem is better than working around it.

+1 for right-bias

[√iktor Ҡlang]

On Tue, May 15, 2012 at 1:49 PM, Rob Dickens <robcd...@gmail.com> wrote:

How about doing the following:

* leave Either as it is, since the name doesn't imply any bias
(although Right certainly does), and it looks like changing it would
only buy you definitions in for-comprehensions (and not having to add
.right)

* introduce a completely new class, Checked, having OK and KO as the
type constructors

* include support for combining Checked values in both a fail-fast and
fail-slow manner, including applicative-functor support (<*>
operator), similar to that which I describe here:

http://robsscala.blogspot.co.uk/2012/05/validating-multiple-values-at-once.html

That kind of thinking gave use java.util.Data and then java.util.Calendar, just sayin'.

Cheers,

√

[Miles Sabin]

On Mon, May 14, 2012 at 8:08 AM, Jason Zaugg <jza...@gmail.com> wrote:
> (A follow-up from ticket SI-5793. [1])
>
> Apologies in advance to any left-handers out there.
>
> I propose (not that I'm the first) to right-bias Either. Concretely,
> this means we would add map/flatMap etc directly to Either, rather
> than going through RightProjection. RightProjection could probably
> deprecated.
>
> Is there any previous discussion on this? Any arguments against?

Also a +1 from me ...

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
g+: http://www.milessabin.com
http://twitter.com/milessabin
http://underscoreconsulting.com
http://www.chuusai.com

[Kevin Wright]

At the very least, as an interim solution, could we have a publicised and advocated import to enable this behaviour?

scala> implicit def doTheRightThing[A,B](x: Either[A,B]): Either.RightProjection[A,B] = x.right

doTheRightThing: [A, B](x: Either[A,B])Either.RightProjection[A,B]

scala> val one: Either[Int,String] = Right("Bippy")

one: Either[Int,String] = Right(Bippy)

scala> val two: Either[Int,String] = Left(42)

two: Either[Int,String] = Left(42)

scala> one map {_.toUpperCase}

res0: Product with Either[Int,java.lang.String] with Serializable = Right(BIPPY)

scala> two map {_.toUpperCase}

res1: Product with Either[Int,java.lang.String] with Serializable = Left(42)

Assuming, of course, that it could be done without any performance cost :)

[Rex Kerr]

I might agree with at least adding an import.  (Especially if there was also a left-bias one could import.)

And I would _probably_ +1 the right-bias of Either as a whole (not just with an implicit) if I knew exactly what this meant.  Right now it seems like we're giving +1 for something like "justice"--who can be against justice (or kittens)?  But what exactly does it mean?

I'd rather show or reserve enthusiasm on the basis of an exact proposal (especially now that it's clearly established that the right-bias of Either would be widely accepted in principle).

In particular, I'm especially interested in how Option and Either are supposed to interact, in capabilities for recovering good states from error states and tossing away provisionally good states into error states, and in having complete (not partial) support for for-comprehensions.

For example, suppose we make Either look like RightProjection:

  val e: Either[Int,String] = Right("fish")
  for (x <- e.right if true) yield x

We get a deprecation warning about withFilter not existing, and with filter instead of getting the value we get neither an Option[String] nor an Either[_, String] but an Option[Either[Nothing,String]].  Wha?  That's not very helpful for composition.

As another example, suppose I look something up in a map:

  val m = Map("fish" -> true)
  e.right.map(m.get)

Now I have an Either[Int, Option[Boolean]].  This is probably not what I want, and it's certainly not what for wants:

  for (x <- e.right; y <- m.get(x)) yield y
  // type mismatch; found: Option[Boolean] required: Either[?,?]

You can get this to work longhand

  e.right.flatMap((m.get _) andThen {o => o.toRight(-1)})

but what a mess!

These sorts of issues are, I think, why Try has the semantics that it does.  Try can work properly for error handling; right-biased Either is still full of holes.  I am _not_ keen on right-biasing Either only to have it fall apart as soon as you try anything but the simplest things with it.

So I think we should try to find an implementation of right-biased Either that has good properties, and then decide whether or not this is what Either should become--not just ask for a right-biased either without knowing the implementation details.

  --Rex

[OMURA, Shingo]

I also vote +1.

Best regards,
--
Shingo Omura
Software Architect, Technical Translator / Writer
http://everpeace.github.com/


2012/5/16 Rex Kerr <ich...@gmail.com>: