Using multiple sketches in the same class runs a risk of name collisions, meaning at least one needs to use the fully qualified name.
And more generally, it's ambiguous which types of queries an ItemsSketch can handle without additional context. These aren't huge issues, but if we're already going to break API continuity with a major version bump we may as well improve usability at the same time jon On Thu, Jul 22, 2021, 1:29 PM Alexander Saydakov <[email protected]> wrote: > What is the downside of the current naming in your view? > If we decide to do this, I would vote for consistency, and rename Theta > sketches too. > > On Thu, Jul 22, 2021 at 1:06 PM Jon Malkin <[email protected]> wrote: > >> I think our other sketches do things like VarOptItemsSketch, so append >> the family to the front of the name. I'd vote for doing that for the >> non-ItemsSketch variants (e.g. LongsSketch), too, for consistency. >> >> It'd be great to do the same for theta, but that might be a lot more >> painful for both us and library users. >> >> jon >> >> >> On Thu, Jul 22, 2021 at 12:49 PM Alexander Saydakov >> <[email protected]> wrote: >> >>> How do you propose to name them? >>> >>> On Thu, Jul 22, 2021 at 12:47 PM Jon Malkin <[email protected]> wrote: >>> >>>> Watching the traffic on the memory package and how that's setting us up >>>> for a refactoring of the java library, I'd like to suggest we take teh >>>> opportunity of a major version bump to rename a few of our sketches. >>>> >>>> Specifically, we have an ItemsSketch in both quantiles and frequent >>>> items. That might be the only collision, but those don't follow the name >>>> scheme of our other sketches and it means that any code using both must >>>> include the fully qualified name on one of them. >>>> >>>> A major version bump seems like the perfect time to make sure we >>>> resolve such things. >>>> >>>> jon >>>> >>>> >>>>
