Hacker News Reader

Comment by coldtea | Hacker News Reader

>It's interesting, but I can see it leading to much frustration when, as an overrider, you don't want it to run that before/after code.

It's about ensuring the invariants the parent class needs -- not giving subclasses freedom to do whatever they want is meant as a feature.

This allows library designers to design more future proof APIs (since they control more invariants of how they're gonna be extended), and to prevent users of their libs from shooting themselves in the foot.

View on HN

And it requires users that want to override it (a common issue with final stuff on Android) to use native extensions to patch the memory of the parent class at runtime (or use other forms of reflection).

Is there any reason it is common in Andoid to want to override final stuff?

Is it because of a design issue in the Android libraries or to try and circumvent some limitations that might have some reasons to exist?

It is because often you need to do stuff that the system doesn’t allow on older versions.

As updates are rarely ever applied, you have to deal with 10 year old versions frequently.

So you use these tricks to get the same functionality on old versions.

Sometimes you also need to do the same on modern versions, because Google releases UI libraries where everything is final and internal, and so you either have to fork a library with hundredthousands of LOC, or you gotta use reflection.

As on android every library is bundled statically, there’s no risk of anything breaking either.

>(It is because often you need to do stuff that the system doesn’t allow on older versions. As updates are rarely ever applied, you have to deal with 10 year old versions frequently.

That's not a programming problem that this capability allows us to solve though.

That's a management/market/etc problem, that necessitates that we use this method as a kludge to bypass it.

The same is true for the features we're talking about, though. The relationship between the library developers and its users is a social problem, not a programming problem. There's nothing technical that prevents you from changing a non-sealed/virtual/etc API, it's just that you don't want to have people who didn't read or ignored the documentation complaining that their code broke.

Reply on news.ycombinator.com