What is the use case for delegate?

It becomes quite a big issue when tens, if not hundreds of people are creating issues about it. I’d say that is quite an annoyance to the developer. Which shouldn’t have been a problem in the first place, if the owner of the library didn’t have a hard on for wanting to keep everything “private” just because they think it should be. When in reality, it totally depends on the end-user and their use case.

Edit: Also, especially in large open source projects, sometimes the developers don’t even see these kinds of particular issues and don’t really give them any attention, and are not usually fixed until weeks, if not months later. Yet another negative

At this point I’m not sure why anyone is bothering to debate the topic. I do find encapsulation useful, in real-world experience including packages where I am the only developer who works on a package. If you don’t find it useful, then don’t use it.

3 Likes

Problem is, if a developer of a repo does use it, end-users will suffer.
It’s not about “if you don’t find it useful, don’t use it”. It’s about not restricting developers of your library the ability to craft solutions to fix their issue without having to rely on the developer of the project to fix it, or make something “public”.

It’s a much larger issue than “don’t like it, don’t use it”

Why wouldn’t you dig around CS history a bit? You would see quite quickly that the reasons most languages exist revolve around encapsulation and/or modularity, both being ways to separate interface and implementation. There are languages that don’t provide any of this, notably it’s not easy to do in C, though not impossible, but these are rare and far between. AFAIR Python doesn’t have explicit visibility modificators, but it does have underscore notation to the same end.

It’s a much larger issue than “don’t like it, don’t use it”

It is, and ironically you look at it at a narrow angle.

1 Like