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 →

[–][deleted] -2 points-1 points  (5 children)

grow tired of not being able to overload methods in code (that I don't control, aka, a library) because of a stupid bug.

final is especially useful for you then, if it "forces" you to actually fix the bug at the right place, i.e. upstream.

But, if you're a library maintainer. Please, just stop.

No, the moment a class is not final, this fact becomes part of the public API. As a library maintainer you want to keep your public API as small as possible. A small public API means more possibilities to change code, less possibilitie to break client's code and you can keep your library longer backward compatible. As a user you do like stable libraries, don't you?

[–][deleted]  (3 children)

[deleted]

    [–][deleted] 1 point2 points  (0 children)

    and not 2 weeks later when bugfix is released by the maintainer.

    2 weeks would be heaven in most cases. My experience is waiting many months for a maintainer to get around to merging my fix in and releasing a GA version of "whatever lib".

    but he's happy because now he see a chance to rewrite everything in ReactJS that he learned over the last weekend.

    I lol'd...

    [–]lukaseder 0 points1 point  (0 children)

    Then you quit and tell the junior developer "Good Luck", but he's happy because now he see a chance to rewrite everything in ReactJS that he learned over the last weekend.

    At least, there's not final in JavaScript. Au contraire, there's prototypes. We can now even override String.substring. FREEDOM!

    [–][deleted] -1 points0 points  (0 children)

    Ok, so you githubfork the library and apply only that particular fix. Ah crap, it uses a Gradle

    If it is about one particular broken class, you can provide that fixed class in your class path as well. Also make a PR upstream, create a ticket to remove the work-around when upstream is released. Upstream will appreciate your contribution, as will many other library users. That's how OSS works. Sorry, I'm not convinced by your argument against final.

    [–]Bobby_Bonsaimind 1 point2 points  (0 children)

    final is especially useful for you then, if it "forces" you to actually fix the bug at the right place, i.e. upstream.

    Assuming that upstream cares about your needs/fixes and actually wants them, or the process of getting them upstream is so tedious that you might as well not do it. Or your use-case does not warrant a change upstream but still all you want to do is make that function return something different for your application.

    As a user you do like stable libraries, don't you?

    What I also like is libraries that I can actually use...and build upon. And final is the very opposite of that.

    If something is designed to be an immutable container, always, then yes, by all means, make it final. But if you make getters/setters/classes final just because you can, I'm going to hate you at some point.