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

H. Hirzel hannes.hirzel at gmail.com
Thu Oct 5 09:33:57 UTC 2017


Hello Edgar,

Replacing file access with the FileMan API is another issue.
This thread is about the FileList *tool*. [3] .

The FileMan File accessing API may be loaded through SqueakMap (for
5.1, no entry yet for 6.0a).

FileList uses the FileServices registration mechanism [4]. The open
task there is that the initialization code does not yet fully do its
job [5], [6]. See discussion earlier this year in March in which you
took part.

Regards

Hannes



[3] FileList comment:

I am model that can be used to navigate the host file system. By
omitting the volume list, file list, and template panes from the view,
I can also be used as the model for an editor on an individual file.

The FileList now provides a registration mechanism to which any tools
the filelist uses ***MUST*** register.  This way it is possible to
dynamically load or unload a new tool and have the FileList
automatically updated.  This change supports a decomposition of Squeak
and removes a problem with dead reference to classes after a major
shrink.

http://wiki.squeak.org/squeak/1975

------------------------------------------


[4] FileList class
registeredFileReaderClasses
	FileReaderRegistry := nil. "wipe it out"
	^FileServices registeredFileReaderClasses

[5] FileServices -- http://wiki.squeak.org/squeak/1001	

[6] Which file reader classes are not touched by "FileServices
initialize"? -- http://wiki.squeak.org/squeak/1023

On 10/5/17, Edgar J. De Cleene <edgardec2005 at gmail.com> wrote:
> 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
> Enviroments.
>
>
> 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