ironcalc / IronCalc

Main engine of the IronCalc ecosystem
Apache License 2.0
48 stars 2 forks source link

Rethink public API #28

Open nhatcher opened 3 months ago

nhatcher commented 3 months ago

There are two API's right now,

In both cases the API to do anything follows the rule sheet, row, column where sheet is a 0 based sheet index and row and column and 1-base indices. For instance to set some value in a cell we would do:

model.set_user_input(sheet, row, column, value);

This is all good and dandy, but it might not be ideal. we might want to get the sheet first and then do other things:

let mut worksheet = model.get_worksheet(sheet_index)?;
worksheet.set_user_input(row, column, value);

We might even be able to avoid getting the sheet in the first place by using an API that just loops over existing sheets. That would have the advantage of never failing. another advantage would be that looping over a lot of values in the same sheet would be easier

let mut worksheet = model.get_worksheet(sheet_index)?;
for row in 1..10 {
    for column in 1..100 {
        worksheet.set_value(row, column, value);
    }
} 

Another thing we need to think is the names of the methods. In Rust it is customary not to use the word 'get' for getters like worksheet.column_width(column) but IronCalc at the moment uses get everywhere. The reason is that the API will match better in the general case (other languages) and that it is evident as soon as you see it that it doesn't change the state.

It would be very nice if the APi is discoverable, self describing or intuitive. So we shouldn't be using sometimes the name sheet and others the name worksheet