Fix internal use of deprecated Excelx::Cell.new
#564
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Calling
Excelx#set
internally calledExcelx::Cell.new
, which is deprecated in favor ofExcelx::Cell.create_cell
.I tried using the recommended
Excelx::Cell.create_cell
, however it expects atype
as the first argument.#set
tries to infer the type viacell_type_by_value
, however it only returns:float
or:string
, butExcelx::Cell.cell_class
doesn't support:float
.Even if I add
:float
to map toCell::Number
, then there's a dilemma becauseExcelx::Cell.create_cell
passes all the arguments except the first onto the specific cell class, but the arity ofCell::String
is 5 whereas the arity ofCell::Number
is 6, meaningExcelx#set
would need to initialize each cell class individually to pass the appropriate arguments.Therefore I landed on simply using
Cell::Base
. It's probably not the most accurate, but given persisting the spreadsheet isn't an option, the uses forExcelx#set
should be minimal. In my case, I simply use it in testing to avoid creating new files for every possible scenario, opting to manually set various cells to triggered assorted scenarios.Fixes #529.