4 ms·

Deprecation does not imply removal in the short-term. Java has deprecated many things which will never be removed, because they care about compatibility. Just

by rleigh 6y ago

Deprecation does not imply removal in the short-term. Java has deprecated many things which will never be removed, because they care about compatibility. Just because there's a newer way to do something does not mean the old way must be removed as soon as possible. If it was very high maintenance and it prevented the addition of new functionality, this might be justified. But that's not the case. It's completely gratuitous. The GTK+ removals are akin to removing "strlen()" from the C library because a better "strlengh()" was added in the meantime. Compatibility matters. And well-maintained projects balance that with the addition of new features.

chris_wot 6y ago
Perhaps there should be a raft of functions in the C library that are deprecated and removed.
- rleigh 6y ago
  Deprecated, perhaps, should suitable replacements be standardised. Removed, absolutely not. It cannot be overstated just how terrible compatibility breaks are. C is nearly 50 years old, and all of its standard functions are thoroughly entrenched, despite their numerous known defects. It took long enough to eliminate gets(), and that was broken from inception. In almost all cases, removal is not the best solution. Supplementing with a safer or better alternative to supersede the original, by all means. But deliberate breakage causes nothing but pain all around. In the case of GTK+, it's nearly 25 years old. These is a legacy of thousands of applications, large and small, which have invested hundreds of thousands of developer-hours in it. Obsoleting things might save the GTK+ developers a little extra effort (though I doubt this), but it imposes several orders of magnitude more work upon the worldwise developer base tied to GTK+, which could be avoided entirely without holding back progress.
  - chris_wot 6y ago
    So you expect the developers to keep maintaining old interfaces forever? The C library, that I understand (POSIX and all), but GTK+? I think that's an unnecessary burden. Now if someone wanted to make a shim library that had the old APIs, that might be doable.
    - rleigh 6y ago
      It all comes down to impact. Removing an unused and long-deprecated interface is low impact. Removing a widely-used interface is very high impact. When you have an interface that is nearly 25 years old and a staple part of every GTK+ application in existence... that's a very high impact change. I'm unsure how the GTK+ developers rationalised that one. But I am completely certain they made the wrong call there. It's too disruptive. I don't think it should have ever been dropped, or considered for dropping. Deprecated, yes. But not dropped. I'm coming from the perspective of an end-user of GTK+: an application developer. Though I have historically also contributed bits upstream. I moved away from using GTK+ several years back at this point, precisely because the upstream maintenance practices were too much of an ongoing imposition, along with all the other criticisms one can make of it. GTK+ might be "free", but the cost of using it is very, very high.
      - cycloptic 6y ago
        There are 800 deprecated symbols in GTK 3. They were removed in GTK 4 because nobody upstream is willing to pay the cost to maintain them anymore. There is a real cost and typically this cost is that you have to commit to bugfixes and refactoring on the deprecated bits for the entire lifecycle of the new version, which is potentially many years. If the app developers aren't willing to pay the cost either, then you've got a hung jury situation.

by rleigh 6y ago

chris_wot 6y ago

Perhaps there should be a raft of functions in the C library that are deprecated and removed.

rleigh 6y ago
Deprecated, perhaps, should suitable replacements be standardised. Removed, absolutely not. It cannot be overstated just how terrible compatibility breaks are. C is nearly 50 years old, and all of its standard functions are thoroughly entrenched, despite their numerous known defects. It took long enough to eliminate gets(), and that was broken from inception. In almost all cases, removal is not the best solution. Supplementing with a safer or better alternative to supersede the original, by all means. But deliberate breakage causes nothing but pain all around. In the case of GTK+, it's nearly 25 years old. These is a legacy of thousands of applications, large and small, which have invested hundreds of thousands of developer-hours in it. Obsoleting things might save the GTK+ developers a little extra effort (though I doubt this), but it imposes several orders of magnitude more work upon the worldwise developer base tied to GTK+, which could be avoided entirely without holding back progress.
- chris_wot 6y ago
  So you expect the developers to keep maintaining old interfaces forever? The C library, that I understand (POSIX and all), but GTK+? I think that's an unnecessary burden. Now if someone wanted to make a shim library that had the old APIs, that might be doable.
  - rleigh 6y ago
    It all comes down to impact. Removing an unused and long-deprecated interface is low impact. Removing a widely-used interface is very high impact. When you have an interface that is nearly 25 years old and a staple part of every GTK+ application in existence... that's a very high impact change. I'm unsure how the GTK+ developers rationalised that one. But I am completely certain they made the wrong call there. It's too disruptive. I don't think it should have ever been dropped, or considered for dropping. Deprecated, yes. But not dropped. I'm coming from the perspective of an end-user of GTK+: an application developer. Though I have historically also contributed bits upstream. I moved away from using GTK+ several years back at this point, precisely because the upstream maintenance practices were too much of an ongoing imposition, along with all the other criticisms one can make of it. GTK+ might be "free", but the cost of using it is very, very high.
    - cycloptic 6y ago
      There are 800 deprecated symbols in GTK 3. They were removed in GTK 4 because nobody upstream is willing to pay the cost to maintain them anymore. There is a real cost and typically this cost is that you have to commit to bugfixes and refactoring on the deprecated bits for the entire lifecycle of the new version, which is potentially many years. If the app developers aren't willing to pay the cost either, then you've got a hung jury situation.