feat!: Introduce new ReadOnlyOrderedSet super-interface

[luanpotter]

Introduce new ReadOnlyOrderedSet super-interface.
Also makes all sets Queryable, removing the prior distinction.

[github-actions]

Benchmark Results

Package ordered_set:

Benchmarks	Current Branch [luan.new-interface]	Base Branch [main]	Diff
Iteration Benchmark - Comparing	234.055 μs	240.419 μs	🟢 -2.647 %
Insertion and Removal Benchmark - Comparing	459.386 μs	359.066 μs	🔴 +27.939 %
Comprehensive Benchmark - Comparing	15946.720 μs	15422.264 μs	🔴 +3.401 %
Iteration Benchmark - Priority	248.818 μs	254.865 μs	🟢 -2.373 %
Insertion and Removal Benchmark - Priority	320.834 μs	286.030 μs	🔴 +12.168 %
Comprehensive Benchmark - Priority	14881.548 μs	14743.285 μs	🔴 +0.938 %

---

Benchmarks provided with 💙 by Dart Benchmark Action.

[luanpotter]

dart doesn't allow named and optional parameters on the same function sadly:
https://dart.dev/language/functions

honestly I am considering just making the compare function mandatory, and then removing the "default compare" nastyness

[spydon]

It's quite nice to be able to just plug in Comparables without having to specify the compare function though, because that is supported today right?
Not sure if we should think of other users than Flame for this package, because maybe there are none. 😅

[coveralls]

Pull Request Test Coverage Report for Build 15165692203

Details

• 66 of 68 (97.06%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+2.9%) to 97.512%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/comparing_ordered_set.dart	12	13	92.31%
lib/ordered_set.dart	14	15	93.33%

Files with Coverage Reduction	New Missed Lines	%
lib/ordered_set.dart	1	95.92%

Totals
Change from base Build 14360619647:	2.9%
Covered Lines:	196
Relevant Lines:	201

---

💛 - Coveralls

[luanpotter]

Note: the performance drop on insert is due to strictMode being active by default on all ordered sets now.

[spydon]

Note: the performance drop on insert is due to strictMode being active by default on all ordered sets now.

I'd say it would be better to have it deactivated by default? And then if the user uses query in a way that requires pre-caching before the first call everywhere they'd just activate strict mode, and then all the other users wouldn't suffer the performance loss on insertion.

[luanpotter]

@spydon maybe we can call it queryCaching have 3 modes:

DISABLED (default) - do not pre-register and just errors if query or whereType are used
PRE_REGISTER
ON_DEMAND

[spydon]

@spydon maybe we can call it queryCaching have 3 modes:

DISABLED (default) - do not pre-register and just errors if query or whereType are used
PRE_REGISTER
ON_DEMAND

I don't see why the disabled one is needed? And I would have on demand as the default instead.

[luanpotter]

@spydon the disable one is to teach users the best way of doing things, otherwise they will just use query all the time and never know they are paying a penalty

[spydon]

@spydon the disable one is to teach users the best way of doing things, otherwise they will just use query all the time and never know they are paying a penalty

But I'm not sure that most use the query feature (if this package even has some other users than Flame 😂), and then they will get the performance penalty without getting anything for it.

[luanpotter]

why would they get a performance penalty with the default disable mode? it is quite the opposite...

[spydon]

why would they get a performance penalty with the default disable mode? it is quite the opposite...

Ah yeah, sorry, I meant if there would only be two modes and pre-register would be the default. Let's go with disabled then!

[luanpotter]

LGTM!