Change Expressive.Expressions.Binary.BinaryExpressionBase scope from internal to public

Loving this library! It is making my life SO much easier for a big project - except for one small keyword.

I’m setting up a custom Context subclass for our project so that it automatically registers some new custom functions and replaces some other built-in functions on construction. Creating the custom functions was was a breeze to do, just by making implementations of FunctionBase. The constructor also unregisters the bitwise operators, paving the way to use ‘^’ as an exponent operator so we can respect the expression syntax defined in our user interface spec.

• First step: make an implementation of OperatorBase - no problem.
• Next step: make an implementation of BinaryExpressionBase - problem.

Overriding EvaluateImp was straightforward, but unlike FunctionBase and OperatorBase which are declared public, BinaryExpressionBase is declared internal.

Can BinaryExpressionBase be made public instead of internal?

I really don’t want to fork and modify just for this keyword - I would really prefer leaving the Expressive package intact and just extend it!

[graniero]

Super! I’ll continue the conversation in those two spots, but a couple quick teasers:

• The caret is crucial to preserve as standard bitwise XOR for people doing bit work, but for people using caret as standard exponent symbol, I’ll guess most are probably not doing bit work. Based on that assumption I have an idea that can cover this without breaking code. I’ll put details at #86.
• Yeah, IgnoreCase is mighty tricky. The idea of a boolean argument for Contains etc. is excellent, and I can think of cases where those functions’ Ignore mode would need to be treated differently than a context-wide 'ignore case for parsing function names etc.` and ‘ignore case for equality tests’. I also have an idea how to separate options for parsing and equality without introducing a breaking change. I’ll put details at #77.

[bijington]

Fixed and shipped in release v2.3.0