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

Edgar J. De Cleene edgardec2005 at gmail.com
Thu Oct 5 08:47:02 UTC 2017

We should move to new File system.
My choice is Juan Vuletich enhancements of original FileMan.
This could be a case for Enviroments , having two file systems at once until
all fell confortable with new File system,then rip older and move new out of

On 10/4/17, 20:35, "tim Rowledge" <tim at rowledge.org> wrote:

> 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?

More information about the Squeak-dev mailing list