Hacker News new | ask | show | jobs
by scotty79 372 days ago
It's always app dev responsibility. They can't excuse a bug or lack of functionality with "that's what's in the lib".

I can't imagine somebody monkey patching exposing internals of a lib and blaming lib author for poor effects.
1 comments
simoncion 371 days ago
How are they to distinguish between what are internals and what is the public interface if the internals aren't locked behind something like 'private'? Naming convention? [0] Code comments, or other documentation? A thorough reading of the codebase?

[0] Good luck with enforcing the One True Naming Convention.

link
scotty79 371 days ago
That's why I suggested it should be an annotation at most, so you can convey the intent without limiting the users.

It can still be using keywords like public, protected, private. Just make them non-binding. In similar manner how TypeScript types are non-binding. You can ignore them in any program that uses TS lib.

link
simoncion 368 days ago
> ...so you can convey the intent without limiting the users. It can still be using keywords like public, protected, private. Just make them non-binding.

Yeah, the users aren't likely to be really limited these days.

1) A huge number of widely-used languages have reflection, so you can get at internal members if you really try.

2) For those languages that don't, just remove the keyword and recompile. Someone who's willing to take on the maintenance burden of directly using parts of the software marked by their author as "internal only do not use" is clearly willing to maintain such a minor fork.

link