Refactor _option_list.py to consistently use accessors

[BenMarkFrost]

As noticed in #2985, the _options_list.py file can be organised better to consistently use accessor functions such as get_option_by_index() instead of directly accessing _options.

I'm happy to implement this if it's the direction we want to go in? @rodrigogiraoserrao

[davep]

Not sure if it's relevant here or not, but it's worth keeping in mind that all other things being equal, we tend to go with the most direct route to a value to keep the code as efficient as possible.

[rodrigogiraoserrao]

That's a fair point @davep.
Now, I'm left wondering why we have the get_option_by_index, then.
Is it just for public consumption, and internally we go straight to _options?

[davep]

Now, I'm left wondering why we have the get_option_by_index, then.

Yes, that's part of the public interface.

To be clear though: I'm not setting a hard rule here, just dropping in a driveby reminder that normally our PRs will get a review along the line of "fewer calls please". Personally I'm a fan of building abstraction on abstraction but I see the value in keeping it as streamlined as possible internally (mostly if it's something that's likely to be called often).

[willmcgugan]

I don't think this is needed. It's fine for methods to use internal symbols.

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.