Possible Changes for Version 2.0

[MarkBaker]

I'm planning version 2.0 with some bc breaks, and I'm looking at dropping methods like setCellValueByColumnAndRow() which accepts column and row number arguments, leaving only setCellValue() which requires a cell address as a string value(e.g. 'C5').
There are 14 such methods defined in the WorkSheet class:

• setCellValueByColumnAndRow() has equivalent setCellValue()
• setCellValueExplicitByColumnAndRow() has equivalent setCellValueExplicit()
• getCellByColumnAndRow() has equivalent getCell()
• cellExistsByColumnAndRow() has equivalent cellExists()
• getStyleByColumnAndRow() has equivalent getStyle()
• setBreakByColumnAndRow() has equivalent setBreak()
• mergeCellsByColumnAndRow() has equivalent mergeCells()
• unmergeCellsByColumnAndRow() has equivalent unmergeCells()
• protectCellsByColumnAndRow() has equivalent protectCells()
• unprotectCellsByColumnAndRow() has equivalent unprotectCells()
• setAutoFilterByColumnAndRow() has equivalent setAutoFilter()
• freezePaneByColumnAndRow() has equivalent freezePane()
• getCommentByColumnAndRow() has equivalent getComment()
• setSelectedCellByColumnAndRow() has equivalent setSelectedCells()

and other methods that only accept a cell address like IV255.

There are also one column-only method:

• getColumnDimensionByColumn() has equivalent getColumnDimension()

---

Should I just drop those methods?

Or should I modify setCellValue() (and the equivalent methods for all the above) to accept either a string cell value (C5) or an array [3,5]

setCellValue(string|array $coordinate, $value){}

Or even introduce a new CellAddress object?

setCellValue(string|CellAddress $coordinate, $value){}

or

setCellValue(string|array|CellAddress $coordinate, $value){}

An array is less structured: should it be row first, or column first? Should [3,5] refer to cell C5 or cell E3?

A CellAddress object could be defined with static creator methods like fromRowAndColumn($rowIndex, $columnIndex), fromColumnAndRow($columnIndex, $rowIndex), fromCoordinate($cellAddress), etc; and provide getters to retrieve rowIndex, columnIndex, columnString, cellAddress, etc, giving it a lot more flexibility.

[MarkBaker]

I haven't found an option for a poll here on github discussions, but I am running a poll on twitter

[MarkBaker]

So for deprecating setCellValueByColumnAndRow(3, 5, $value), developers should use the equivalent setCellValue('C5', $value) instead.

And the options to modify setCellValue() would allow passing the cell address as at present (setCellValue('C5', $value)); possibly an array of column/row (setCellValue([3,5], $value)), and potentially a new CellAddress object (setCellValue(new CellAddress('C5'), $value)).

In turn, a new CellAddress object could be created with static constructors like $cellAddress = CellAddess::fromColumnAndRow(3, 5);

[MarkBaker]

And while I've been thinking through the possibilities of a CellAddress object over the last few days, there's also potential for

new CellRange(new CellAddress('C3'), new CellAddress('E5'))

to provide cell range C3:E5 for those functions that accept a cell range as an argument

[MarkBaker]

Results of the poll:

[pwaring]

I've just come across this - is the removal of setCellValueByColumnAndRow definitely going ahead? If so, is there a way to mark it in the documentation so that developers are aware and don't add new code using it that will break when they upgrade? (I'm happy to make a PR for the docs, but I don't know if there is a standard way of marking functions as to be removed). At the moment there's no indication that the functionality is going to be removed, e.g. on:

https://phpspreadsheet.readthedocs.io/en/latest/topics/accessing-cells/#setting-a-cell-value-by-column-and-row

[oleibman]

@pwaring The functions in question all have @deprecated tags in their DocBlocks, and that is recognized by many IDE's, and by the "API documentation" at https://phpoffice.github.io/PhpSpreadsheet/. As you have pointed out, the "official documentation" does not mention this and probably should. I'll look into what needs to be done.

[oleibman]

@pwaring Documentation has now been updated with PR #3816.

[PowerKiKi]

Since v2 has been released this topic can probably be closed