|
|
|
|
|
by sixcorners
2208 days ago
|
|
So are you saying you no longer think OO inherently makes things harder to test? I feel like it's difficult to talk about this without examples.
The library I like thinking about when I think of passing around in a state variable is the lua C api. https://www.lua.org/pil/24.1.html here is an example. https://pgl.yoyo.org/luai/i/lua_State here are docs for the state variable's type. This is pretty object oriented except that it's not using C++'s syntax sugar. You can't really do much with L except pass it into other lua "methods". The discussion up until your comment seems to be about the difference between using the syntax sugar and passing around a state variable yourself. Information hiding and these other implementation details are kind of seperate. In my example you can't just configure L exactly how you want by messing around with it or inspecting its state directly. You have to go through accessor "methods". I think if the argument is that OO promotes information hiding I can agree with that. I'm not sure about the point about the internal state becoming a part of the API though. APIs are contracts that can be met with different implementations right? If your implementation details are public then your contract is huge and inflexible. |
|
Since using this API makes an implicit constraint that it is using a stack underneath the hood, why not just expose the stack for inspection? What advantage does keeping it an opaque blob have? I agree you don't want code manipulating this stack (although if it is immutable as in FP this isn't an issue), but since the external code already knows it is a stack and relies on that fact then it is part of the public API already.