Channels
#core
Title
# core
t
theopolis
02/22/2021, 10:23 PM
For the chrome extensions PR, I’m cautious about the new textfile read API. I think that’s considerable debt if we don’t treat it carefully. I’d rather see a PR to introduce that new API, then migrate existing places that would benefit over, then adapt chrome extensions to improve by using it.
s
seph
02/23/2021, 12:13 AM
Okay. Let’s see what @alessandrogario says
a
alessandrogario
02/23/2021, 7:07 PM
I'll remove it, I think my main concern with the primitives we have is that they are too complex and don't return much other than a Status 1 when something fails, with no way to tell if the open has errored for one reason or the other
And since there is no interface in front of it (i.e. a formal error code) we can't just return a special, magic value inside Status to the caller
we also have legacy code that still checks the integer inside Status to tell whether the operation has failed or not, and even the Status::ok() method makes assumptions on what a valid integer value is
So instead of trying to add special integer values inside the readFile functions we have, I wrote a more correct, modern implementation that only performs a single task (and allows the caller to do proper error handling)
Ideally, in the future we move away from Status and start using the Expected class we have (and move to std::expected when released)
s
seph
02/23/2021, 7:38 PM
sounds like something reasonable to try to change. But maybe in a separate PR?
2 Views