ArraySeq is boxing on map.

[Rich2]

ArraySeq is currently aliased as Arr. See Discourse and Scala-issues

[Rich2]

So I'm looking for some level of unification of immutable compile time Array wrappers and ProductVals. ProductVals should at some point be generalised to compound Value types. All of the Array based types should have both an immutable Array based wrapper and an extensible ArrayBuffer based type.

These will all be based on an implicit builder. I'm not sure if the user methods such as map, mapBuff, flatMap, flatMapBuff, iMap etc should be implemented in the calling class or in the Builder.

So each type will have:

1. An immutable Array based class. Only the AnyRef type will be covariant.
2. An extensible ArrayBuffer based class.
3. A builder.
4. An Eq instance.
5. A persist Instance that may combine the Eq instance.
6. A Companion object for 1, that may be able to at least partly auto-create the Eq, Persist and Builder instances..

If we have a Class Ma and we want to map it to Nb

class Ma
{  def map[Nb](f: A => B)(implicit ev: Builder[Nb]): Nb
}

The method should definitely not be implemented on the Nb class. Nor should the setElem methods be on the Ma class or Nb, only on the Builder.

[Rich2]

@w0d Could you look at Util//test/src/ostrat/ArrTest.scala. I want to get user's perspective on the functionality, and the naming. Does it look straightforward and comprehensible. I've still got to implement the ArrBase interface for ProductVals but I think it should be fairly straightforward.

[Rich2]

That last commit had the wrong message. Should say ProductVals now extends ImutArr

[w0d]

not too bad for me - could work most of it out and the rest from assuming the tests are true (negating the need to grab the scala reference book) though i did stumble with ar1,ar2, ar12 as following the definition for Refs led to the class & object definitions and i wasn't sure which one was pertinent to understanding the code logic (though i got the gist from scanning both) didn't follow the use of s in the val names is1 through to ds5 at first but since writing this i guess its because it plural? ints1 etc much better as is1 for a test sounds more likely to be a val holding 1

[Rich2]

@w0d Hopefully naming is clearer now.

[w0d]

:) On Monday, 6 April 2020, 20:59:47 BST, Rich notifications@github.com wrote:

Closed #79 via ac965fc.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe.