7 ms·
Sometimes I actually want objects that are transparent, fully public, and 'struct' is perfect for that. But if I then go and put methods into those structs, doe
by greenbit 3mo ago
Sometimes I actually want objects that are transparent, fully public, and 'struct' is perfect for that. But if I then go and put methods into those structs, does that make me unorthodox?
- badlibrarian 3mo ago[flagged]
- blashyrk 3mo agoThat's simply because we live in a world where UFCS is restricted to niche languages and we're stuck with "methods" instead. At least Rust/Kotlin/Swift support type extensions (with a thousand papercuts, i. e orphan rules)
- rramadass 3mo agoNo, it is perfectly valid if your design demands it. For example, the Windows MFC framework had classes whose data members were all public. Some of reasons were; 1) MFC was a wrapper over lower-level Windows API/structs and therefore unnecessary getter/setter methods were avoided. The C++ class could be a simple wrapper over the underlying C-style POD. 2) The framework classes were supposed to be used by implementation inheritance to build one's skeleton application which led to tight coupling between base and derived classes. Hence the designers decided to make all members public which meant that users were not limited by any omissions in the basic design. I actually used these ideas in a project where i implemented a C++ api over C state machines for H.323 protocols.