A concise way to express this match?

I would write it as:

root.find {case Schema("HR") => true; case _ => false}

On Fri, Aug 6, 2010 at 4:26 PM, Pedro Lopes <paol@draic.org> wrote:

Hi, a quick style question:

I have a tree structure of heterogeneous nodes (as case classes).
In the unit tests for this structure I ended up with dozens of
find/filter/exists calls that look like something like this:

root.find {
 _ match {
   case Schema("HR") => true
   case _ => false
 }
}

This works well, but is terribly verbose. This sort of "boolean
match":

_ match {
 case Schema("HR") => true
 case _ => false
}

feels like it should be expressible in more compact form. Is there
a better way?

Thanks,
Pedro

It looks like you're trying to find the first Schema("HR") value in some collection `root`
So why not:

root.find{ _ == Schema("HR") }

case class already have equality properly defined for you :)


On 6 August 2010 20:26, Pedro Lopes <paol@draic.org> wrote:

Hi, a quick style question:

I have a tree structure of heterogeneous nodes (as case classes).
In the unit tests for this structure I ended up with dozens of
find/filter/exists calls that look like something like this:

root.find {
 _ match {
   case Schema("HR") => true
   case _ => false
 }
}

This works well, but is terribly verbose. This sort of "boolean
match":

_ match {
 case Schema("HR") => true
 case _ => false
}

feels like it should be expressible in more compact form. Is there
a better way?

Thanks,
Pedro

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On 08/06/2010 09:03 PM, Rodrigo Cano wrote:
> I would write it as:
>
> root.find {case Schema("HR") => true; case _ => false}
>

Thanks! I wasn't aware the match could be omitted.

Maybe still not as concise as I would like, but at least it's
short enough to be condensed into a single line, which makes a
huge difference.

Pedro

On 08/06/2010 09:12 PM, Kevin Wright wrote:
> It looks like you're trying to find the first Schema("HR") value in some collection `root`
>
> So why not:
>
> root.find{ _ == Schema("HR") }
>
> case class already have equality properly defined for you :)

Sorry, I omitted the fact that the classes I want to match
(Schema in this example) are abstract, so I can't do that.

Pedro

root collect { case x : Schema("HR") => x }

collect is a bit like map, but instead accepts a PartialFunction and filters on the input domain.



On 7 August 2010 12:16, Pedro Lopes <paol@draic.org> wrote:

On 08/06/2010 09:12 PM, Kevin Wright wrote:

It looks like you're trying to find the first Schema("HR") value in some collection `root`

So why not:

   root.find{ _ == Schema("HR") }

case class already have equality properly defined for you :)

Sorry, I omitted the fact that the classes I want to match
(Schema in this example) are abstract, so I can't do that.

Pedro

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Hi,

how about this:

root.view.collect { case x @ Schema("HR") => x } headOption

- Andreas

Am 06.08.2010 um 21:26 schrieb Pedro Lopes:

> Hi, a quick style question:
>
> I have a tree structure of heterogeneous nodes (as case classes).
> In the unit tests for this structure I ended up with dozens of
> find/filter/exists calls that look like something like this:
>
> root.find {
> _ match {
> case Schema("HR") => true
> case _ => false
> }
> }
>
> This works well, but is terribly verbose. This sort of "boolean
> match":
>
> _ match {
> case Schema("HR") => true
> case _ => false
> }
>
> feels like it should be expressible in more compact form. Is there
> a better way?
>
> Thanks,
> Pedro
>
>

of course...  @ not :
Schoolboy error on my part!

On 7 August 2010 15:09, Andreas Flierl <andreas@flierl.eu> wrote:

Hi,

how about this:

root.view.collect { case x @ Schema("HR") => x } headOption

- Andreas

Am 06.08.2010 um 21:26 schrieb Pedro Lopes:

> Hi, a quick style question:
>
> I have a tree structure of heterogeneous nodes (as case classes).
> In the unit tests for this structure I ended up with dozens of
> find/filter/exists calls that look like something like this:
>
> root.find {
>  _ match {
>    case Schema("HR") => true
>    case _ => false
>  }
> }
>
> This works well, but is terribly verbose. This sort of "boolean
> match":
>
> _ match {
>  case Schema("HR") => true
>  case _ => false
> }
>
> feels like it should be expressible in more compact form. Is there
> a better way?
>
> Thanks,
> Pedro
>
>

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On 08/07/2010 03:09 PM, Andreas Flierl wrote:
> Hi,
>
> how about this:
>
> root.view.collect { case x @ Schema("HR") => x } headOption
>

Interesting, why does the above pattern not require the _ case?
I would have expected that code to throw MatchError, but it doesn't.

Pedro

It's because collect is exactly for that. Collect takes a partial function pf and only considers the values in the underlying collection for which pf is defined, applies pf to them and builds a new collection containing only them.

scala> List(None, Some(1), Some(2), None, Some(42), None, None).collect { case Some(n) => n }
res0: List[Int] = List(1, 2, 42)

- Andreas

Am 07.08.2010 um 20:17 schrieb Pedro Lopes:

> On 08/07/2010 03:09 PM, Andreas Flierl wrote:
>> Hi,
>>
>> how about this:
>>
>> root.view.collect { case x @ Schema("HR") => x } headOption
>>
>
> Interesting, why does the above pattern not require the _ case?
> I would have expected that code to throw MatchError, but it doesn't.
>
> Pedro
>
>

an incomplete match expression becomes a PartialFunction`collect` eats *those* for breakfast...

On 7 August 2010 19:17, Pedro Lopes <paol@draic.org> wrote:

On 08/07/2010 03:09 PM, Andreas Flierl wrote:

Hi,

how about this:

root.view.collect { case x @ Schema("HR") =>  x } headOption

Interesting, why does the above pattern not require the _ case?
I would have expected that code to throw MatchError, but it doesn't.

Pedro

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

To add another detail, if I'm not mistaken, basically when you write a PartialFunction, scalac compiles your pattern match twice: once doing essentially what you wrote, as the body of the apply method; and it also compiles a boolean version for the body of the isDefinedAt method. So code that consumes a PartialFunction can call isDefinedAt in order to know whether apply will throw a MatchError.

On Sat, Aug 7, 2010 at 2:31 PM, Andreas Flierl <andreas@flierl.eu> wrote:

It's because collect is exactly for that. Collect takes a partial function pf and only considers the values in the underlying collection for which pf is defined, applies pf to them and builds a new collection containing only them.

scala> List(None, Some(1), Some(2), None, Some(42), None, None).collect { case Some(n) => n }
res0: List[Int] = List(1, 2, 42)

- Andreas

Am 07.08.2010 um 20:17 schrieb Pedro Lopes:

> On 08/07/2010 03:09 PM, Andreas Flierl wrote:
>> Hi,
>>
>> how about this:
>>
>> root.view.collect { case x @ Schema("HR") =>  x } headOption
>>
>
> Interesting, why does the above pattern not require the _ case?
> I would have expected that code to throw MatchError, but it doesn't.
>
> Pedro
>
>

Depending on your code, you could do something like this:
def isA[A](pf: PartialFunction[A, Unit]) = pf.lift(_: A) != Noneval testHR = isA[SuperClass] { case Schema("HR") => }
then you can do root.find(testHR(_))

On Fri, Aug 6, 2010 at 4:26 PM, Pedro Lopes <paol@draic.org> wrote:

Hi, a quick style question:

I have a tree structure of heterogeneous nodes (as case classes).
In the unit tests for this structure I ended up with dozens of
find/filter/exists calls that look like something like this:

root.find {
 _ match {
   case Schema("HR") => true
   case _ => false
 }
}

This works well, but is terribly verbose. This sort of "boolean
match":

_ match {
 case Schema("HR") => true
 case _ => false
}

feels like it should be expressible in more compact form. Is there
a better way?

Thanks,
Pedro

--
Daniel C. Sobral

I travel to the future all the time.