Fix internal use of deprecated Excelx::Cell.new#564
Open
cgunther wants to merge 1 commit intoroo-rb:masterfrom
Open
Fix internal use of deprecated Excelx::Cell.new#564cgunther wants to merge 1 commit intoroo-rb:masterfrom
Excelx::Cell.new#564cgunther wants to merge 1 commit intoroo-rb:masterfrom
Conversation
Calling `Excelx#set` internally called `Excelx::Cell.new`, which is deprecated in favor of `Excelx::Cell.create_cell`. I tried using the recommended `Excelx::Cell.create_cell`, however it expects a `type` as the first argument. `#set` tries to infer the type via [`cell_type_by_value`](https://github.com/roo-rb/roo/blob/709464c77623be2bc09b2103405d90ded7604a75/lib/roo/base.rb#L175-L182), however it only returns `:float` or `:string`, but `Excelx::Cell.cell_class` doesn't support `:float`. Even if I add `:float` to map to `Cell::Number`, then there's a dilemma because `Excelx::Cell.create_cell` passes all the arguments except the first onto the specific cell class, but the arity of `Cell::String` is 5 whereas the arity of `Cell::Number` is 6, meaning `Excelx#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 for `Excelx#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 roo-rb#529.
cgunther
force-pushed
the
fix-cell-new-deprecation
branch
from
c927ee5 to
40ddfac
Compare
|
Is there any chance this PR will get merged and released? Our logs are absolutely spammed by this warning. Alternatively, is there a way we can get it to display only once instead of every time it's called? |
|
Hey all - I know you're all really busy, but is there any chance of merging this in and getting a fresh version of this gem released to rubygems? |
|
Does anyone know if there is any update on getting this deprecation fixed? Either in this PR or another. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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#setinternally calledExcelx::Cell.new, which is deprecated in favor ofExcelx::Cell.create_cell.I tried using the recommended
Excelx::Cell.create_cell, however it expects atypeas the first argument.#settries to infer the type viacell_type_by_value, however it only returns:floator:string, butExcelx::Cell.cell_classdoesn't support:float.Even if I add
:floatto map toCell::Number, then there's a dilemma becauseExcelx::Cell.create_cellpasses all the arguments except the first onto the specific cell class, but the arity ofCell::Stringis 5 whereas the arity ofCell::Numberis 6, meaningExcelx#setwould 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#setshould 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.