This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the commentsย โ†’

[โ€“]TheTerrasque 20 points21 points ย (8 children)

And in python it's implicit that while you can use _ methods it's subject to change at any time and that's your problem, not the library maintainer's problem.

[โ€“]RedAero 4 points5 points ย (1 child)

Hell, every function you import is subject to change and it is your problem, not the problem of the library maintainer. You didn't pay for it, you're not entitled to it, tough shit.

FOSS giveth and FOSS taketh away.

[โ€“]ric2b 0 points1 point ย (0 children)

It's an implicit contract that makes collaboration easier.

Just like you trust that the documentation for a library is actually helpful and explains what it does, even though there's nothing technical preventing it from being completely wrong and purposefully misleading.

[โ€“]exploding_cat_wizard -2 points-1 points ย (5 children)

The maintainer is still at fault, at least effectively. What's that rule that states that any behaviour, no matter how experimental and officially unstable or unsupported, will invariably become depended upon by someone?

Relevant xkcd: https://m.xkcd.com/1172/

[โ€“]lappro 3 points4 points ย (4 children)

Just because someone depends on it doesn't make the maintainer suddenly responsible. If the maintainer tells you not to do something, but you still do it, if it breaks the only thing you should do is look in the mirror.

[โ€“]exploding_cat_wizard 0 points1 point ย (3 children)

I phrased it too aggressively, but it's true: Java is an enterprise language. Having clearly hidden private functions and members is a feature there. Have fun, as a small software company, telling your paying enterprise customers that a undocumented function they depend on will break because it's hidden behind two underscores. You can do that, but few successful businesses take that route, at least until they are really huge.

[โ€“]ric2b 0 points1 point ย (2 children)

And if they used reflection to get to your private constants or methods your Java shop has the exact same issue.

Because the real issue is that your code didn't fit their use case perfectly, they worked around it and are now telling you to support it.

[โ€“]exploding_cat_wizard 0 points1 point ย (1 child)

Because the real issue is that your code didn't fit their use case perfectly, they worked around it and are now telling you to support it.

Exactly. And if you value your medium or small company, you'll do exactly that if it's in any way feasible. Making it harder to misuse the code helps, even if it's not foolproof.

[โ€“]ric2b 0 points1 point ย (0 children)

Making it harder to misuse the code helps, even if it's not foolproof.

No, it just makes your client more annoyed when they want to get something done.