[squeak-dev] FileList2>listForPattern(s): and MessageSend abuse
hannes.hirzel at gmail.com
Thu Oct 5 00:00:05 UTC 2017
And there is no FileList2 in Pharo.
On 10/5/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Thank you for the analysis, Tim.
> Noteworthy that FileList2 has a class comment from 2003.
> But it seems FileList2 goes back at least to version 3.0 (screen
> shot). It seems it was introduced as an experiment for extending
> FileList and then later was never fully integrated.
> As FileList is built via the ToolBuilder it seems worthwile to focus
> on extending that and get rid of FileList2.
> On 10/5/17, tim Rowledge <tim at rowledge.org> wrote:
>>> On 03-10-2017, at 12:59 PM, tim Rowledge <tim at rowledge.org> wrote:
>> [snip everything but the randomly chosen sigline]
>>> Two wrongs are only the beginning.
>> Too true in this case. As I look through and trace the code involved in
>> FileList and it’s subclasses I’m struck (forcefully) by the amazing
>> appallingness of it.
>> Some highlights of the horror movie -
>> - FileList is referred to in 70 places, FileList2 in 33. Which one is
>> to be our standard UI for files? No idea.
>> - When opening a default FileList (from the dock menu for example) the
>> contents of the default directory are read and processed twice. This may
>> seem a big deal, unless perhaps you have a thousand or more files in a
>> directory, or your default directory is across a network, or you machine
>> slow etc. It’s stupid, whatever.
>> - A FileList2 seems to double that stupidity.
>> - There are strange artefacts of what looks like partial attempts to
>> in EToys support, left to bitrot.
>> - Why would a FileList be a subclass of StringHolder?
>> - A default FileList is built via the ToolBuilder. FileList2 adds a load
>> non-TB ways to build.
>> - The look of different variants of secondary dialogues built from
>> FileList* vary wildly. Some have rounded blue frames. Some look like
>> ‘normal’ windows.
>> - Some variants show a directory hierarchy by adding spaces in front of
>> path elements. Others use a hierarchy displaying morph. The
>> list is built even when not needed.
>> - FileChooser adds yet another layer of ‘interest’ but appears totally
>> - PluggableFileList appears to only actually get used within MVC world,
>> which is just as well since the morph version is rather ugly; it also
>> to be only referred to usefully from StandardFileMenu, which makes an
>> especially odd thing since the code reads as asking for a menu and you get
>> dialogue/window. And in some places the code alternately requests a
>> StandardFileMenu and a FileList! Talk about causing confusion. As an
>> bit of fun, the fact that it got squeezed into place as if a menu means
>> it has to implement assorted menu messages like #startUpWithCaption:
>> I think we’re probably at the point where a completely new file accessing
>> model is needed in order to try to obsolete this nest of nightmares.
>> of course, someone can point to a nice replacement already written and
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Strange OpCodes: RLB: Ruin Logic Board
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 144141 bytes
Desc: not available
More information about the Squeak-dev