Removal of nsILocalFile and other interfaces, was: Upcoming change to fixIterator function in iteratorUtils.jsm
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Tue Aug 8 18:33:07 UTC 2017
On 8/8/2017 1:09 PM, Ben Bucksch wrote:
> I would suggest to keep such interfaces. an empty interface is not
> really a maintenance burden. and adding this file will be 100 times
> easier than fixing all callers, even if it's just a replacement.
> this is particularly true for extensions without maintainer. it's the
> user that counts, not who is at fault. this is a relatively easy way
> to avoid unnecessary breakage.
> you might be able to just undo these m-c commits, or (to avoid changes
> to m-c) move the IDL files to a new dir in mailnews/compat/src/public/.
I'm going to push back on this. nsILocalFile was blanked out on
2012-04-05. That's 5 years it's done absolutely nothing, and any
extension maintained in the intervening period has had more than ample
opportunity to fix it. It's also wrong to say that it's not a
maintenance burden. It is: we'd have to make the ns*File implementations
support nsILocalFile for its QI support. This requires forking
mozilla-central or maintaining a copy of a forked file. If you don't
maintain the nsILocalFile QI support, then you'd *still* break most of
the extensions that would hypothetically use it. You're adding
maintenance burden for literally zero gain. Also, the interface itself
has seen two substantive commits in the intervening period, necessitated
by XPIDL semantic changes (the likes of which should not be ruled out
for the future).
Finally, we've had long discussions about the impacts of technical debt
on our codebase. Advocating for keeping a compatibility shim that
Mozilla is unwilling to keep requires substantial justification.
Certainly, it requires far more than "maybe it will keep unmaintained
5-year old addons working."
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning