Question

Suppose you have a table widget class.

Do you do table.row(i).column(0).setText(students[i].surname())
or table[0][i] = students[i].surname()

the latter makes way less sense but the simplicity is so luring ;)

ditto for: table.row(0).column(0).setBackground(red)
vs: table[0][0].setBackground(red)

Note that Table::row returns a Table::Row, whose column function returns a Table::Cell, and Table::Cell provides either setText or op= (as well as setBackground).
Same for Table::op[] and Table::Row::op[].

Your thoughts?

Was it helpful?

Solution

The solution with Table::row() and Table::Row::column() methods is a bit more readable (in general) and allows you to unambiguously create a Table::column() method, Table::Column (proxy) class, and Table::Column::row() method later on, if that is ever needed. This solution also makes it easy to find all places where rows/columns are accessed, which is much harder when you use operator overloading.

As others pointed out however, the second solution is less typing and, in my opinion, not much worse in readability. (May even be more readable in certain situations.)

It's up to you to decide though, I'm just giving some implications of both solutions :-)

OTHER TIPS

As a less verbose alternative for many common cases, I would also provide something like this:

table.rowcol(i, j) = "blah"; // rowcol returns directly a cell
table.colrow(k, t).SetBackground(black);

Basically the name of the method just serves as a reminder on the order of the parameters. Also, being a single method, you can perform better exception handling IMO.

The second one. It carries just as much meaning as the first and is hugely easier to read and to type.(I don't really understand why you say it makes "way less sense".)

Actually you'd do neither of those. They are both buggy code and could lead to exceptions if there are no rows.

if(table.rows > 0)
{
    var row = table.row[0];
    if(row.columns > 0)
    {
        var col = row.column[0];
        etc...
table.row(i).column(0)

This style is known as the Named Parameter Idiom. This makes it easy to reorder a set of calls in any way that pleases you as an alternative to positional parameters. However, this works provided each of the chained calls return the same original object. Of course, in your case you have a row object and a column object. So, there isn't much to gain here.

The ease of use of the second construct provides another compelling reason to choose the latter over the former.

There is not a way which is better than another. It depends on what you have to do with your data structure.

That said, for a simple table widget (assuming you are not coding a complex Excel-like application) I'd seek easy syntax instead of a more general interface. So table[0][1] = "blah" would just work fine for me.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top