This is needed because some code asks for a path to the file without having a File. For example SpecialUndelete::showFile(). Basically encapsulation punch-through. This is a clean-up. If you disagree, of course feel free to propose something else.
On Wed, Oct 19, 2011 at 6:06 PM, Platonides Platonides@gmail.com wrote:
El 19/10/11 21:41, Russell Nelson escribió:
In order to support viewing deleted files (currently a blocker bug in SwiftMedia), I'm going to refactor File::getPath() into a new public function File::getLocalPath(), which will return an instance of a new class TempLocalPath, which will have two methods: getPath(), and close(). This class will own a local copy of the file. When it goes out of scope or its close() method is called (same thing), any resources held by the class will be freed.
>
With the upcoming FileBackend class and subclasses, this class will be a requirement. Since I need it anyway, I may as well do the work now to create it. File::getPath() will remain as a call, but it will throw an exception if SwiftMedia is installed. When I get finished, its only uses will be by extension writers who have chosen not to publish their code in our SVN.
Why is this needed? A FileSwift class which needed to fetch the file from Swift could acquire it when calling getPath(), and have it deleted on FileSwift destruction (getPath() is usually called from several methods, so it isn't practical to acquire and destroy every time).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l