yeah we can do that I will look into it but I am not sure if we should rather let that patch bake in for a bit and then do that change in a second issue. Would make debugging simpler if we run into problems.
I agree, that case is crazy today and it shouldn't block nor confuse the issue. I just wanted us to have a plan for the file format. Otherwise there is no point in writing OMIT_NORMS bit in the fieldinfoswriter because it could be represented by normValueType of 0.
I agree, maybe its better to get this right in this patch already I can still move the stupid file checks removed in a second issue. But I should really handle null types ie. Sims that don't set a value, currently I have tons of asserts that enforce a value.
This isn't a huge deal though, its mostly just curiousity. Previously you always had to return something, we didnt even have the option for a sim (like basic tf * idf) to not encode any length normalization information. The way you had to do that before was to return a bogus byte in computeNorm and ensure you always did omitNorms for the field.
If its tricky or messy, in my opinion we could even just add an assertion for now and document "you must set something" in Similarity, because its a lower level API than it was in previous release (most people would generally extend higher level stuff like BM25Similarity, TFIDFSimilarity, or even DefaultSimilarity that do not expose this stuff).