Page MenuHomePhabricator

MediaWiki's file class hierarchy is crazy
Open, LowPublicFeature

Description

The File class (and related classes) should have a clearer class hierarchy.

*ArchivedFile doesn't extend anything
Besides all the duplicated code, this means that people who use "File" type hints, may be in for a nasty surprise

*ForeignDBFile is a subclass of LocalFile
This just doesn't really make sense logically. Even if code wise there isn't much difference, having a new class, say DBFile, that both LocalFile and ForeignDBFile extend, with perhaps minimal code in the new LocalFile class.

*Subclasses seem to be made on 2 dimensions - is the file current/old/deleted, and the repo type of the File. This should maybe be investigated if this is really a good way of splitting things up.


Version: unspecified
Severity: enhancement

Details

Reference
bz58479

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:22 AM
bzimport set Reference to bz58479.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 28032 has been marked as a duplicate of this bug. ***

FYI, https://gerrit.wikimedia.org/r/179402 tries to standardise File's constants and methods to match Revision's.

Jdforrester-WMF renamed this task from File class hierarchy is crazy to MediaWiki's file class hierarchy is crazy.Sep 4 2015, 6:37 PM
Jdforrester-WMF lowered the priority of this task from Medium to Low.
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.
Jdforrester-WMF set Security to None.
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM

ArchivedFile not extending the File class has caused the need for a hacky workaround in the MediaModeration extension (the same used by ArchiveFile::pageCount).

It would be very useful if the ArchivedFile class could extend the LocalFile class. Does anyone know of particular reasons why this wouldn't work in practice?