FileList2>listForPattern(s): and MessageSend abuse

FileList2>listForPattern(s): and MessageSend abuse

FileList2 has both #listForPattern: and #listForPatterns: I cannot find any usage of the #listForPattern: and it also looks like it might be a left over from some EToys experiment. Given the possibilities of confusion between the tow I’d prefer to remove it.

Both methods also try to handle having the fileSelectionBlock be a MessagesSend, and do it horribly. Using #isKindOf: is not a nice thing.
a) I can’t find any place where a MessageSend is actually meaningfully used except an EToys method where a Block would be at least as good and easier to understand, so why even have the option?
b) the usage seems poor - why set the arguments, evaluate the MS and then empty the arguments instead of simply treating it as a Block? I might be missing some subtlety of MessageSend I suppose, but given the mess of code in that class I wouldn’t be surprised.

Does anyone know why we shouldn’t remove #listForPattern: and clean out the (mis)use of MessageSend in #listForPatterns: ?

Re: FileList2>listForPattern(s): and MessageSend abuse

FWIW, #listForPattern: was the original
method many moons ago. FileList had one version and then
FileList2 had another that was more attuned to EToys. The plural
patterns version came along sometime after 2001.

On 10/3/17 3:59 PM, tim Rowledge wrote:

FileList2 has both #listForPattern: and #listForPatterns: I cannot find any usage of the #listForPattern: and it also looks like it might be a left over from some EToys experiment. Given the possibilities of confusion between the tow I’d prefer to remove it.
Both methods also try to handle having the fileSelectionBlock be a MessagesSend, and do it horribly. Using #isKindOf: is not a nice thing.
a) I can’t find any place where a MessageSend is actually meaningfully used except an EToys method where a Block would be at least as good and easier to understand, so why even have the option?
b) the usage seems poor - why set the arguments, evaluate the MS and then empty the arguments instead of simply treating it as a Block? I might be missing some subtlety of MessageSend I suppose, but given the mess of code in that class I wouldn’t be surprised.
Does anyone know why we shouldn’t remove #listForPattern: and clean out the (mis)use of MessageSend in #listForPatterns: ?
tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Two wrongs are only the beginning.

Re: FileList2>listForPattern(s): and MessageSend abuse

> On 03-10-2017, at 12:59 PM, tim Rowledge <[hidden email]> 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?

>
>> On 03-10-2017, at 12:59 PM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim> Strange OpCodes: RLB: Ruin Logic Board
>
>
>
>

Re: FileList2>listForPattern(s): and MessageSend abuse

> 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 <[hidden email]> wrote:
>>
>>> On 03-10-2017, at 12:59 PM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim>> Strange OpCodes: RLB: Ruin Logic Board
>>
>>
>>
>>
>

Re: FileList2>listForPattern(s): and MessageSend abuse

It was an experiment from the summer of
2000. It was where expandable hierarchical directory lists were
added. It also added some features that were wanted in EToys at
the time. Some time later, some of its features were rolled back
into FileList.

Change Set: multiProjects4
Date: 16 June 2000
Author: Bob Arning

- introducing some FileList variants using hierarchical lists.
The main reason is to create some simplified file locators for
loading projects, but you may want to use this in other
circumstances as well.

On 10/4/17 7:48 PM, H. Hirzel wrote:

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.

Re: FileList2>listForPattern(s): and MessageSend abuse

> On 04-10-2017, at 5:26 PM, Bob Arning <[hidden email]> wrote:
>
> It was an experiment from the summer of 2000. It was where expandable hierarchical directory lists were added. It also added some features that were wanted in EToys at the time. Some time later, some of its features were rolled back into FileList.

Thanks Bob. I’m glad someone can remember that far back!

Don’t suppose you recall anything about why it is subclassed from StringHolder? That really does seem odd...

Re: FileList2>listForPattern(s): and MessageSend abuse

On 10/4/17 9:27 PM, tim Rowledge wrote:
>> On 04-10-2017, at 5:26 PM, Bob Arning <[hidden email]> wrote:
>>
>> It was an experiment from the summer of 2000. It was where expandable hierarchical directory lists were added. It also added some features that were wanted in EToys at the time. Some time later, some of its features were rolled back into FileList.
> Thanks Bob. I’m glad someone can remember that far back!
Doesn't take remembering - just open up a 2.9 image.
>
> Don’t suppose you recall anything about why it is subclassed from StringHolder? That really does seem odd...
Well, the whole point is to provide a view of the contents of a file
which you can read, edit and save. The rest is just how to get that
content in the first place. So, it's a StringHolder with some extra
buttons attached.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim> Computer and car salesmen differ in that the latter know when they are lying.
>
>
>

Re: FileList2>listForPattern(s): and MessageSend abuse

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.

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

Re: FileList2>listForPattern(s): and MessageSend abuse

Hi, there.

We should distinguish between (1) tools for artifacts and (2) the artifacts themselves. That is, cleaning-up FileList and FileList2 is a different challenge than moving to a new file system, which would also need appropriate tools.

Let's not mix those up but keep focus during discussions if possible. ;-)

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 untilall fell confortable with new File system,then rip older and move new out ofEnviroments.

On 10/4/17, 20:35, "tim Rowledge" 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?

Re: FileList2>listForPattern(s): and MessageSend abuse

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.

> 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" <[hidden email]> 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?
>
>
>
>
>

> 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 <[hidden email]> 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" <[hidden email]> 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?
>>
>>
>>
>>
>>
>

> Note: What [4] FileList class registeredFileReaderClasses
> says is that in the olden days FileList acted as a file registry.
>
> This is now done by FileServices [5] but is does not do it for all cases
> [6].
>
>
> On 10/5/17, H. Hirzel <[hidden email]> wrote:
>> 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 <[hidden email]> 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" <[hidden email]> 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?
>>>
>>>
>>>
>>>
>>>
>>
>

Re: FileList2>listForPattern(s): and MessageSend abuse

>
>> On 03-10-2017, at 12:59 PM, tim Rowledge <[hidden email]> 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.

Re: FileList2>listForPattern(s): and MessageSend abuse

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.

Re: FileList2>listForPattern(s): and MessageSend abuse

> Well, the whole point is to provide a view of the contents of a file which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.

Ah, right, as previously mentioned a case of is-a or has-a. I much prefer has-a myself.

> Well, the whole point is to provide a view of the contents of a file which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.

Ah, right, as previously mentioned a case of is-a or has-a. I much prefer has-a myself.

Re: FileList2>listForPattern(s): and MessageSend abuse

On 10/5/17, Nicolas Cellier <[hidden email]> wrote:
> I note that most references to FileList are for registering/unregistering a
> specific tool as a service for a specific fileType...
> So the goal is to make file services modular/pluggable/extendable.
> What I don't understand is that FileList seems to duplicate FileServices
> code (see for example implementors of #registerFileReader)...

> P.S.: it seems that we abused a bit of living system metaphor.
> It's like we wanted to create diversity in order to multiply the chances of
> squeak to survive ;)
> Unfortunately, natural selection of code doesn't obey fair rules:
> - code tends to bloat and complexify over years
> that could be like our cells that gradually degenerate...
> - but the worse code (the most complex) tend to survive longer.
> this is because it becomes more and more complex to change it without
> breaking features.
> and breaking features is frowned upon...
>
> In biology, the immune system also help eliminating own degenerated cells.
> I don't see anything equivalent in Squeak.
> So the whole organism is in danger if we don't help the bad cells to die ;)
>
> 2017-10-05 20:04 GMT+02:00 tim Rowledge <[hidden email]>:
>
>>
>> > On 04-10-2017, at 6:48 PM, Bob Arning <[hidden email]> wrote:
>> >>
>>
>> > Well, the whole point is to provide a view of the contents of a file
>> which you can read, edit and save. The rest is just how to get that
>> content
>> in the first place. So, it's a StringHolder with some extra buttons
>> attached.
>>
>> Ah, right, as previously mentioned a case of is-a or has-a. I much prefer
>> has-a myself.
>>
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim>> Oxymorons: New classic
>>
>>
>>
>>
>

> On 10/5/17, Nicolas Cellier <[hidden email]> wrote:
>> I note that most references to FileList are for registering/unregistering
>> a
>> specific tool as a service for a specific fileType...
>> So the goal is to make file services modular/pluggable/extendable.
>> What I don't understand is that FileList seems to duplicate FileServices
>> code (see for example implementors of #registerFileReader)...
>
>
> FileServices was introduced with Squeak 3.9 in November 2006
>
> http://wiki.squeak.org/squeak/1001>
>> And that there is a random mixture of usage:
>>
>> ChangeList class>>initialize
>> FileList registerFileReader: self
>>
>> ChangeSet class>>initialize
>> "ChangeSet initialize"
>> AllChangeSets == nil ifTrue:
>> [AllChangeSets := OrderedCollection new].
>> self gatherChangeSets.
>> FileServices registerFileReader: self.
>>
>> What do you suggest instead? Who should survive?
>
>> P.S.: it seems that we abused a bit of living system metaphor.
>> It's like we wanted to create diversity in order to multiply the chances
>> of
>> squeak to survive ;)
>> Unfortunately, natural selection of code doesn't obey fair rules:
>> - code tends to bloat and complexify over years
>> that could be like our cells that gradually degenerate...
>> - but the worse code (the most complex) tend to survive longer.
>> this is because it becomes more and more complex to change it without
>> breaking features.
>> and breaking features is frowned upon...
>>
>> In biology, the immune system also help eliminating own degenerated
>> cells.
>> I don't see anything equivalent in Squeak.
>> So the whole organism is in danger if we don't help the bad cells to die
>> ;)
>>
>> 2017-10-05 20:04 GMT+02:00 tim Rowledge <[hidden email]>:
>>
>>>
>>> > On 04-10-2017, at 6:48 PM, Bob Arning <[hidden email]> wrote:
>>> >>
>>>
>>> > Well, the whole point is to provide a view of the contents of a file
>>> which you can read, edit and save. The rest is just how to get that
>>> content
>>> in the first place. So, it's a StringHolder with some extra buttons
>>> attached.
>>>
>>> Ah, right, as previously mentioned a case of is-a or has-a. I much
>>> prefer
>>> has-a myself.
>>>
>>>
>>> tim
>>> --
>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim>>> Oxymorons: New classic
>>>
>>>
>>>
>>>
>>
>

Re: FileList2>listForPattern(s): and MessageSend abuse

> On 05-10-2017, at 12:47 PM, Nicolas Cellier <[hidden email]> wrote:
>
> In biology, the immune system also help eliminating own degenerated cells.
> I don't see anything equivalent in Squeak.
> So the whole organism is in danger if we don't help the bad cells to die ;)