tag:blogger.com,1999:blog-6115154198867082591.post7686855860176725328..comments2021-12-08T22:44:42.640-08:00Comments on Cleverly Titled Blog: Disjoint Bounded Views - ReduxMitch Blevinshttp://www.blogger.com/profile/09476167560094979019noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6115154198867082591.post-13782809005451497172010-04-06T10:29:49.000-07:002010-04-06T10:29:49.000-07:00I see what you are suggesting now. It really does...I see what you are suggesting now. It really does simplify the code! All the example usages I had considered did not actually call any of the implicit conversion methods, just tricked the type-checker into ensuring that only certain types got passed to the method. Your example actually exercises the conversion code. See post for updated implementation.Mitch Blevinshttps://www.blogger.com/profile/09476167560094979019noreply@blogger.comtag:blogger.com,1999:blog-6115154198867082591.post-90664433579799669662010-04-06T07:47:23.992-07:002010-04-06T07:47:23.992-07:00What I meant is that instead of defining the case ...What I meant is that instead of defining the case class DisjointBoundedView, you'd use 'Either'. Then, the object DisjointBoundedView would still provide all the implicit conversions (da is Left, db is Right). type 'or' will be an alias to Either.<br /><br />The example will work the same<br /><br />The benefit is that if I want to store the parameter, I can do this using a standard object (Either) instead of DisjointBoundedView. <br /><br />var someSet = Set[Int or String or Double]() <br />def bar[T <% Int or String or Double](t: T) {<br /> someSet += t<br />}Ittay Drorhttps://www.blogger.com/profile/06786072335349487451noreply@blogger.comtag:blogger.com,1999:blog-6115154198867082591.post-48908352022158928392010-04-06T07:38:53.246-07:002010-04-06T07:38:53.246-07:00The motivation was to provide a way to define a me...The motivation was to provide a way to define a method that is overloaded in a way that would normally be disallowed due to erasure. For example, how to provide a method that accepts a Set[Int] or a Set[String] without giving up type-safety by using Set[Object]? Requiring an Either[Set[Int],Set[String]] pushes the conceptual load back onto the users of your method, not to mention the method signature change if you allow an additional type (add Set[Double]?).Mitch Blevinshttps://www.blogger.com/profile/09476167560094979019noreply@blogger.comtag:blogger.com,1999:blog-6115154198867082591.post-10001456385443771312010-04-06T07:02:39.599-07:002010-04-06T07:02:39.599-07:00Isn't it better to use Either than to define a...Isn't it better to use Either than to define a new class?Ittay Drorhttps://www.blogger.com/profile/06786072335349487451noreply@blogger.com