TASK: Remove floating point numbers and arithmetic operations from language core

[grebaldi]

solves: #27

Remaining TODOs

• Rename NumberLiteralNode to IntegerLiteralNode
• Rename NumberType to IntegerType
• Remove arithmetic operators from BinaryOperator enum
• Remove arithmetic operators from TokenType enum
• Remove exponents from Parser
• Remove floating points
  • from Parser
  • from NumberFormat
• Rename NumberFormat to IntegerFormat

[mhsdesign]

Fine for now, as this is required to move forward with #31

And as arithmetics were currently broken either way (see issue)

But it might be that we need to reevaluate this topic again at some later point. The argumentation in #27 might not be enough to convince any developer ^^. Also we should have a tutorial how to migrate calculations from components (because i think they will probably lurke in some dark fusion corner of some fusion project)

Also i assume that its currently to late to say no to this change either way because we value #31 - please correct me if im wrong ^^

[grebaldi]

@mhsdesign:

But it might be that we need to reevaluate this topic again at some later point.

We can always add those concepts back, if the respective need comes up. Although I do believe that numbers and arithmetics should actually not be part of the language, removing them right now is more about loosing weight before the ongoing major refactorings :D

The argumentation in #27 might not be enough to convince any developer ^^. Also we should have a tutorial how to migrate calculations from components (because i think they will probably lurke in some dark fusion corner of some fusion project)

Hmm... I don't know, if we're on the same page here 🤔

I see it like this:

The component engine is all about supporting a very specific architectural approach (namely: presentation objects). It has nothing in common with Fusion, other than being somewhat inspired by it and operating in a strict subset of the same problem space (but offering a very different solution).

In relation to Fusion - as of right now - the component engine aims to stand as an alternative view framework for Neos and Flow. This is however a secondary concern to it being a standalone library. I believe that looking at it through a backwards-compatible-to-fusion lens will lead to considerable feature-creep and runs counter the purpose of the overall approach. (Though I do think, an interoperable-with-fusion lens is perfectly viable)

The aim should not be to replace Fusion. If the component engine proves to be viable, this might happen on its own some day - that's up to people's choice, really :).

I'm pretty sure that projects that use presentation objects today are very likely to replace fusion with the component engine right away, because it precisely replaces the parts of fusion that are still used for rendering over there. I also think it's possible that, with the help of the component engine, more people will adopt presentation objects.

However, it is just as possible that presentation objects will remain a niche-approach. That would be fine with me, but I get the impression that this is a troubling thought to you. If that is so, we should definitely talk things through to see how we can reconcile our ideas.