[squeak-dev] FileList2>listForPattern(s): and MessageSend abuse

H. Hirzel hannes.hirzel at gmail.com
Wed Oct 4 23:48:26 UTC 2017


Thank you for the analysis, Tim.

Noteworthy that FileList2 has a class comment from 2003.
http://wiki.squeak.org/squeak/2379

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.

--Hannes

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 meant
> 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 not
> 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 is
> slow etc. It’s stupid, whatever.
>  - A FileList2 seems to double that stupidity.
>  - There are strange artefacts of what looks like partial attempts to hack
> 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 of
> 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 space-formatted
> list is built even when not needed.
>  - FileChooser adds yet another layer of ‘interest’ but appears totally
> unused.
>  - PluggableFileList appears to only actually get used within MVC world,
> which is just as well since the morph version is rather ugly; it also seems
> 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 a
> dialogue/window. And in some places the code alternately requests a
> StandardFileMenu and a FileList! Talk about causing confusion. As an extra
> bit of fun, the fact that it got squeezed into place as if a menu means that
> 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. Unless,
> of course, someone can point to a nice replacement already written and
> functional?
>
>
> tim
> --
> 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...
Name: FileList2_in_Squeak3.0_Screenshot.png
Type: image/png
Size: 40046 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171005/d8ae0342/attachment.png>


More information about the Squeak-dev mailing list