Algorithms should be free from rich types

[Steven Schveighoffer]

On 7/3/23 2:05 PM, H. S. Teoh wrote:
> 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.

But that's the thing, there are parts that *simply must be private*. No 
matter how you cut it, it has to have some level of privacy, because 
otherwise, you can't enforce semantic invariants with the type.

Should array length (not the property, but the actual data field) be 
public? What about the pointer? Of course not. Yet, you still might want 
to access those things for some reason. That doesn't mean it's worth a 
change to public just for that one reason.

> 
> 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.

It's easy to talk about this in general terms, like "let you tweak more 
things", but when you start talking about non-abstract real cases, 
usually the reason for private data becomes obvious.

The thing is, if it does make sense that something should just be 
public, making it public is easy, just make a PR to do it, and the 
benefits/drawbacks can be discussed, planned for, and agreed upon. Going 
the other way is much much worse.

If you provide public access, it then becomes a supported API. I 
remember one case in the past, some type in phobos had undocumented 
members that were public due to laziness or carelessness.

When the code had to change to a different implementation, we had to 
deprecate that access for years before actually changing. It was horrid. 
There is a real cost to careless publicity.

-Steve