- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
copyMap
Tue, 2011-02-22, 22:35
I realize nobody is likely to be much in the mood for additional stuff,
but it's not always easy to portion things out: I once again found
myself want it, it only took me a minute to implement, so... copyMap?
(Name might be suboptimal.)
scala> (9, "bippy", List(1, 2, 3))
res3: (Int, java.lang.String, List[Int]) = (9,bippy,List(1, 2, 3))
scala> res3.copyMap(f2 = List.fill(4)(_))
res4: (Int, List[java.lang.String], List[Int]) = (9,List(bippy, bippy,
bippy, bippy),List(1, 2, 3))
The generated implementations all look like this, from Tuple3:
def copyMap[U1, U2, U3](
f1: T1 => U1 = Function.identity[T1],
f2: T2 => U2 = Function.identity[T2],
f3: T3 => U3 = Function.identity[T3]
): Tuple3[U1, U2, U3] = {
new Tuple3(f1(_1), f2(_2), f3(_3))
}
No anonymous objects are created were harmed in the making of this
method: weight addition is very low.
I only generated it for tuples, but it could be generalized further, all
the way to being a peer with the synthetic copy on case classes were we
so inclined. It'd be a little interesting to implement (have to
propagate the type constraints so the result is still a Foo, etc.) but
not bad. In the meantime I'd totally use it on tuples.
A possible alternative, and over time I lean more and more this way
anyway, is to generate them somewhere other than the instances.
Slightly less convenient to use, but less likely to trouble anyone.
Wed, 2011-02-23, 02:07
#2
Re: copyMap
On 23/02/2011, at 10:18 AM, Jason Zaugg wrote:
> On Tue, Feb 22, 2011 at 10:35 PM, Paul Phillips wrote:
>> I realize nobody is likely to be much in the mood for additional stuff, but
>> it's not always easy to portion things out: I once again found myself want
>> it, it only took me a minute to implement, so... copyMap? (Name might be
>> suboptimal.)
>
> We call it mapElements in Scalaz. I named the parameters _1, ... _N.
> We've also got fold and toIndexedSeq [1] [2]
>
>> I only generated it for tuples, but it could be generalized further, all the
>> way to being a peer with the synthetic copy on case classes were we so
>> inclined. It'd be a little interesting to implement (have to propagate the
>> type constraints so the result is still a Foo, etc.) but not bad. In the
>> meantime I'd totally use it on tuples.
>
> It's not quite a Zipper [3]. But I would have used it today, for code like:
>
> outer.copy(p1 = outer.p1.copy(p2 = f(outer.p1.p2)))
> outer.copyMap(p1 = _.copy(p2 = f))
A similar construct to copyMap (without named parameters) is called a
congruence in strategic term rewriting:
http://www.program-transformation.org/Stratego/CongruenceOperator
The rewriting part of our Kiama library has a version of congruences as
well, but some setup is required:
http://code.google.com/p/kiama/wiki/Rewriting#Congruences
In the next release of Kiama rewriting will work with most Scala data
structures including collections.
cheers,
Tony
On Tue, Feb 22, 2011 at 10:35 PM, Paul Phillips wrote:
> I realize nobody is likely to be much in the mood for additional stuff, but
> it's not always easy to portion things out: I once again found myself want
> it, it only took me a minute to implement, so... copyMap? (Name might be
> suboptimal.)
We call it mapElements in Scalaz. I named the parameters _1, ... _N.
We've also got fold and toIndexedSeq [1] [2]
> I only generated it for tuples, but it could be generalized further, all the
> way to being a peer with the synthetic copy on case classes were we so
> inclined. It'd be a little interesting to implement (have to propagate the
> type constraints so the result is still a Foo, etc.) but not bad. In the
> meantime I'd totally use it on tuples.
It's not quite a Zipper [3]. But I would have used it today, for code like:
outer.copy(p1 = outer.p1.copy(p2 = f(outer.p1.p2)))
outer.copyMap(p1 = _.copy(p2 = f))
-jason
[1] https://github.com/scalaz/scalaz/blob/master/project/build/Boilerplate.s...
[2] https://github.com/scalaz/scalaz/blob/master/example/src/main/scala/scal...
[3] http://www.scala-lang.org/node/6622