Resolution of null allocation and type ambiguity issues #3
Conversation
this avoids an ambiguity between nothing and nothing[] types, replacing it with a more permissive any[] type.
This allows the item to carry an effective null without making at a nullable object or breaching type correctness. Item will still report null when queried.
|
I am a little uneasy about this PR as it does not seem to be fully addressing the type and structural issues that this code has - the code is mostly autogenerated from jsofa by jsweet and does pass all its unit tests (with the tsconfig options as saved). One problem is the speed of breaking changes that happen in the Typescript/Javascript world, and for instance the ESLint current version has a different configuration that is not backwards compatible. Beginning on the path of making manual edits, I feel should start to address more of the "faults" that exist - An example of one of the transformations that has been done is to replace In other places the typing should probably be tightened to express the real intended difference in meaning between undefined and null |
Array definition from autogenerated call was repetitious and the algorithm could be cleaner and clearer. This has been replaced with a new static fn 'CreateDimensionalArray' Additionally a number of let -> const corrections as called for by ESLint
|
Following the ESLint update, I have remedied all of the issues it currently raised I replaced the anonymous function array allocation with static function that encapsulates the behaviour in a slightly clearer way. I've also resolved all residual ESLint complaints. |
these are returned as the function value - so were overwritten.
This branch corrects both issues #1 and #2 with all tests passing