Algorithms should be free from rich types

[H. S. Teoh]

On Mon, Jul 03, 2023 at 12:32:43PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> The definition of `private` shouldn't change at all. The ability to
> circumvent it still should remain for those wanting to muck with
> internal data, and I don't think there's any way to get around that
> (there's always reinterpret casting). The thing is, it's important to
> identify the *consequences* of changing private data -- it can *never*
> be within spec for a library to allow private data access.
> 
> So one can muck around with private data, and pay the cost of zero
> support (and rightfully so). Or one can petition the library author to
> provide access to that private data.
[...]

I think we all agree that the mechanics of this won't (and shouldn't)
change. But I think the OP was arguing at a higher level of abstraction.
It isn't so much about whether private should be overridable or not, or
even whether some piece of data in an object should be private or not;
the question IMO is whether the library could have been designed in such
a way that there's no *need* for private data in the first place. Or at
least, the need for such is minimized.

A library with tons of private state and only a rudimentary public API
is generally more likely to have situations where the user will be left
wishing that there were a couple more knobs to turn that can be used to
customize the library's behaviour.

A library with less private state, or just as much private state but
with a sophisticated API can lets you tweak more things, would be less
likely to leave the user out in the cold with unusual use cases.
However, it does risk having too many knobs to turn, causing the API to
be far more complex than it ought to be. Which in turn can lead to
unnecessary complexity: the combinatorial explosion of configurations
make it hard for the author to test every combination, so there may be
lots of bugs hidden behind uncommon corner cases.

The ideal library is one where there's almost no private state because
there's no need for it: the code Just Works(tm) for any combination of
values one may assign to the public state.  The API is simple and
concise, yet easily composible and naturally extends to all kinds of use
cases, including unusual ones and ones the author himself never
envisioned -- yet it all just works together naturally.  This ideal may
or may not be attainable, but the closer a library gets to this ideal,
the better.


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?