Hm, maybe the simplest thing to do is to make the abstract class public and let you implement a KeyAnalyzer subclass. Any thoughts on that?
Gary On Thu, Sep 1, 2022, 13:40 Gary Gregory <garydgreg...@gmail.com> wrote: > FWIW, typing as String is a bit restrictive, CharSequence would have been > more reasonable IMO. But we can change that for 4.5.0. > > Gary > > On Thu, Sep 1, 2022, 13:38 Gary Gregory <garydgreg...@gmail.com> wrote: > >> We can make the PT class have generic keys for the next release or create >> a new class with both generic keys and values. >> >> I would prefer 1. That keeps binary compatibility but breaks source >> compatibility which is ok with me. >> >> Gary >> >> On Wed, Aug 31, 2022, 19:16 Willi Schönborn <w.schoenb...@gmail.com> >> wrote: >> >>> Yes, exactly. To be precise, I'm trying to use Kotlin data classes as >>> keys, >>> which are similar to Java records. They have ordered components and I'd >>> require those components to be comparable. >>> >>> On 2022/08/15 20:03:00 Matt Sicker wrote: >>> > Is this like a sort of composite key that‘s ultimately comparable >>> similar >>> to total ordering on strings? >>> > >>> > — >>> > Matt Sicker >>> > >>> > > On Aug 15, 2022, at 08:36, Gary Gregory <ga...@gmail.com> wrote: >>> > > >>> > > Since a trie is traditionally used with strings, this is not >>> surprising to >>> > > me. What kind of key are you wanting to use? >>> > > >>> > > Gary >>> > > >>> > >> On Wed, Aug 3, 2022, 08:16 Willi Schönborn <w....@gmail.com> wrote: >>> > >> >>> > >> I was trying to see whether I could use AbstractPatriciaTrie to >>> create >>> a >>> > >> trie for non-String keys. >>> > >> Especially the existence of the KeyAnalyzer type suggested that I >>> could do >>> > >> this. >>> > >> But the AbstractPatriciaTrie is package-private and not exposed. >>> > >> Was that a conscious decision? >>> > >> >>> > >>> >>
