Split out of #821, which is otherwise done. This is the one item in that pass that cannot be deferred: it is a breaking rename, so 2.0 is either where it happens or where it stops being possible without a second major version.
The inconsistency
Stringize and Latexise are two methods of identical purpose — serialise a node to text — declared side by side, overridden per node, and adjacent in every file they appear in. One is American, one is British.
Measured on 69e3a256:
|
override string … |
identifier occurrences |
Stringize |
65 |
276 |
Latexise |
61 |
189 |
The rest of the public surface is -ize: Stringize (ToString.Definition.cs:15), Entity.Factorize (Evaluation.Definition.cs:350), Integer.Factorize, Serialize / Deserialize. The -ise spelling appears in exactly two public places — Latexise with its ILatexiseable interface (Entity.Definition.cs:86), and MathS.Quantum.Factorise.
The second-order trap
Those two Factor… members are worth naming on their own, because they make the inconsistency actively dangerous rather than merely untidy:
| member |
operation |
Entity.Factorize(int level = 2) |
algebraic factoring of an expression |
MathS.Quantum.Factorise(Entity) |
tensor factorisation of a quantum state |
Two public methods, one letter apart, doing unrelated things. Autocomplete will not save a caller here, and neither will the type system — both take and return the same shapes.
Why it has to be decided now, and not later
Latexise is not an internal name. #822 established that CSharpMath.Evaluation calls it, so the rename is a 61-override change here plus a pull request against another repository. That is exactly the sort of cost a major version exists to absorb, and exactly the sort that is unacceptable in a minor one. Ship 2.0 without deciding and the decision is made by default.
The three ways to go
1. Rename to Latexize, with ILatexiseable → ILatexizeable, and open the CSharpMath PR alongside.
Most consistent, and 2.0 is the only release where the downstream break is legitimate. Cost: 61 overrides, one interface, a BREAKING-CHANGES.md entry, and a coordinated PR in a repository we do not control — which means the two can land out of order and CSharpMath is briefly broken against a 2.0 preview.
2. Keep Latexise, and write down that the library is -ize except here.
Cheapest, and honest as long as it is actually written down rather than left for the next reader to rediscover. The inconsistency stays permanently, since after 2.0 there is no release where removing it is cheap.
3. Add Latexize and keep Latexise forwarding to it.
No break at all — and the wrong answer for this particular release. #832 has just finished deleting 28 members that accumulated exactly this way. Adding a new permanent forwarder in the release whose purpose was removing them would be undoing that work on the same day.
Recommendation
Option 1, on the grounds that option 3 is self-defeating in this specific release and option 2 is only defensible if the write-down actually happens. But this is a public surface with a known external consumer, so it is a maintainer call rather than a contributor one — and option 2 is a perfectly reasonable answer if the CSharpMath coordination is judged not worth it.
Happy to do the work for whichever is chosen, including the CSharpMath side.
Split out of #821, which is otherwise done. This is the one item in that pass that cannot be deferred: it is a breaking rename, so 2.0 is either where it happens or where it stops being possible without a second major version.
The inconsistency
StringizeandLatexiseare two methods of identical purpose — serialise a node to text — declared side by side, overridden per node, and adjacent in every file they appear in. One is American, one is British.Measured on
69e3a256:override string …StringizeLatexiseThe rest of the public surface is
-ize:Stringize(ToString.Definition.cs:15),Entity.Factorize(Evaluation.Definition.cs:350),Integer.Factorize,Serialize/Deserialize. The-isespelling appears in exactly two public places —Latexisewith itsILatexiseableinterface (Entity.Definition.cs:86), andMathS.Quantum.Factorise.The second-order trap
Those two
Factor…members are worth naming on their own, because they make the inconsistency actively dangerous rather than merely untidy:Entity.Factorize(int level = 2)MathS.Quantum.Factorise(Entity)Two public methods, one letter apart, doing unrelated things. Autocomplete will not save a caller here, and neither will the type system — both take and return the same shapes.
Why it has to be decided now, and not later
Latexiseis not an internal name. #822 established thatCSharpMath.Evaluationcalls it, so the rename is a 61-override change here plus a pull request against another repository. That is exactly the sort of cost a major version exists to absorb, and exactly the sort that is unacceptable in a minor one. Ship 2.0 without deciding and the decision is made by default.The three ways to go
1. Rename to
Latexize, withILatexiseable→ILatexizeable, and open the CSharpMath PR alongside.Most consistent, and 2.0 is the only release where the downstream break is legitimate. Cost: 61 overrides, one interface, a
BREAKING-CHANGES.mdentry, and a coordinated PR in a repository we do not control — which means the two can land out of order and CSharpMath is briefly broken against a 2.0 preview.2. Keep
Latexise, and write down that the library is-izeexcept here.Cheapest, and honest as long as it is actually written down rather than left for the next reader to rediscover. The inconsistency stays permanently, since after 2.0 there is no release where removing it is cheap.
3. Add
Latexizeand keepLatexiseforwarding to it.No break at all — and the wrong answer for this particular release. #832 has just finished deleting 28 members that accumulated exactly this way. Adding a new permanent forwarder in the release whose purpose was removing them would be undoing that work on the same day.
Recommendation
Option 1, on the grounds that option 3 is self-defeating in this specific release and option 2 is only defensible if the write-down actually happens. But this is a public surface with a known external consumer, so it is a maintainer call rather than a contributor one — and option 2 is a perfectly reasonable answer if the CSharpMath coordination is judged not worth it.
Happy to do the work for whichever is chosen, including the CSharpMath side.