-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SatelliteData interface should be optional #52
Comments
first thoughts:
|
So this is some very old code, that's why these weird things are in the codebase. I agree that this needs to be cleaner, but I didn't work on this for a while now so I need to wrap my head around it in order to be able to respond to this. What we could do is to have multiple interfaces and one of them has |
Nor sure as I've only been a Kotlin programmer for about 4 hours (literally). Theres a lot of nice 'infix' pimp-my-api stuff could be done but I don't know how that works in mpp etc. |
It is a good idea, but we have to maintain API compatibility with Java. 😢 |
I don't think it's mutually exclusive. if the calculators are simple standalone classes then a "clever" infix layer that glues a them onto suitable |
As an API interface
SatelliteData
is actually a very opinionated choice of data. There is no hard requirement for any enforced supertype to the storage data (e.g. the core class,HexagonalGridImpl
, doesn't use it even once). SatelliteDataexists so Mixite can supply some useful algorithms via the extended
HexagonalGridCalculator. If the user doesn't need
movementCostor
isPassableor
isOpaquethen it's just cruft (note for example
movementCost` is not used anywhere in the code base!).Ergo,
SatelliteData
interface should be optional.However, those additional utilities are very useful and key part of the value of this library.
The text was updated successfully, but these errors were encountered: