Closed julien-truffaut closed 7 years ago
You're right it makes sense for you to provide diagram for concrete implementations. I am mainly interested by a simple Map
diagram in order to visualise Json
In that case what do you think about adding the following?
s.c.i.HashMap
and s.c.i.TreeMap
because that’s low-handing fruitreftree.contrib.SimplifiedInstances.{seq, map}
which would not expose any internal structure, much like https://github.com/stanch/reftree/blob/master/core/src/main/scala/reftree/contrib/SimplifiedInstances.scala#L14I’m open to suggestions w.r.t. the simple map representation. My current idea is to have something like this:
+--------+---------+---------+
| | | |
| Map | • | • |
| | | |
+--------+----X----+----X----+
X XX
XX X
XXXXXXXXXXXXXXXXXX X
XXXXX X
+---X---+-----+-----+ +---X---+-----+-----+
| | | | | | | |
| Entry | foo | 123 | | Entry | bar | 456 |
| | | | | | | |
+-------+-----+-----+ +-------+-----+-----+
Good idea 👍
Ok, I will add that tonight unless you want to contribute :)
I am not sure I will have the time in the next weeks unfortunately :(
Just released 0.7.2
with these changes.
awesome, thank you!
Currently I don’t have any generic instances, e.g. for sets I have
s.c.i.HashSet
ands.c.i.TreeSet
. Addings.c.i.HashMap
ands.c.i.TreeMap
should be trivial (especially the latter, since it reuses 99% of the code ofs.c.i.TreeSet
). Now,Map
points tos.c.i.Map
, which can be a multitude of things. If the map is created viaMap.apply
, it will always be aMap1
,Map2
,Map3
,Map4
or aHashMap
. I can add an instance forMap
with that assumption, but it will break if some other map is passed in. Likewise, an instance forSeq
can be added that assumes aList
(the default forSeq.apply
), but it would fail on everything else. What do you think?