On Saturday, 19 November 2022 at 10:17:19 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 09:51:09 UTC, []() {}() wrote:
...
no. in C# it breaks ABI. that is why its not acceptable in my
team.
of course that's not the reason we don't use public member
variables in classes.
the reason we don't use them, is because (1) we always
anticpiate change including the need to implement (and change)
business rules associated with the objects data (using
setter/getters), and (2) we always prioritise the stability of
the public interface of a class at the time of design.
if neither of those are your concern, in production-level code,
I'd be really surprised (and shocked).
We don't use public members either in most cases - we use them in
simple structs. We have teams that do care and prioritize
stability of public interface because they ship their libraries
to end-users. Other teams care much less because all their users
are internal so they can fix whatever they break.
Regarding ABI compatibility: it's usually driven by what
dependencies your software has. In your case (as far as I got)
you ship .dll that is used by already deployed software so your
library must be ABI compatible with it. In our case, our software
has only system-level dependencies like C runtime, WinSocks so we
don't have such a thing as ABI incompatibility between different
parts of our software but we care about system-level ABI.
