Algorithms should be free from rich types

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Jun 29 23:54:28 UTC 2023


On Thursday, June 29, 2023 8:44:05 AM MDT Atila Neves via Digitalmars-d wrote:
> On Tuesday, 27 June 2023 at 21:53:59 UTC, Ali Çehreli wrote:
> > My mind is not fully clear on this topic yet but some related
> > things have been brewing in me for years.
> >
> > [...]
>
> I have lost count of how many times my life has been made
> difficult by the lack of `private`.
>
> I have also lost count of how many times my life has been made
> easier by the fact that I ruthlessly declare everything `private`
> unless it has good reason not to be.
>
> Ease of refactoring = good, ergo `private` = good and should be
> the default.

Yeah. As with many things, I think that it primarily comes down to good API
design (which can be hard). private prevents implementation details from
being mucked with, which can be a lifesaver when refactoring and can be a
big help with testing and ensuring that things work as expected when other
folks use your code. On the other hand, if you fail to make it so that the
API provides what your users need, then it could easily be the case that
some stuff that should have been available is locked behind private, making
their lives harder (or even impossible, depending on what they're trying to
do).

Similarly, if you actually plan your API around generic types, then it's
much easier for folks to make it work with their own types, but it's not
always obvious when you should be doing that vs designing an API around more
specific types - and it's often the case that code goes from using more
specific types to being more flexible as it matures (though that's harder to
do in cases where you can't reasonably make sure that all user code gets
updated when you make changes, which can make fixing such issues in open
source code harder than in company code).

So, I'm very much in favor of private being the default, but programmers
need to be aware of API issues that can come from being too specific with
APIs and locking away stuff that users may actually need. Experience can
help a lot with that, though it isn't always easy, and there are plenty of
folks out there who just put something together that "works" and leave folks
to deal with the mess when something better thought out would have been far
more useful. Actively trying to come up with good APIs instead of something
that just works can go a long way.

- Jonathan M Davis






More information about the Digitalmars-d mailing list