Smalltalk › Squeak › Squeak - Dev

FileList2>listForPattern(s): and MessageSend abuse

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

timrowledge

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

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Two wrongs are only the beginning.

Bob Arning-2

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.

timrowledge

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

In reply to this post by timrowledge

> 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

Hannes Hirzel

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

FileList2_in_Squeak3.0_Screenshot.png (53K) Download Attachment

Hannes Hirzel

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

And there is no FileList2 in Pharo.

On 10/5/17, H. Hirzel <[hidden email]> wrote:

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

FileList_tool_in_Pharo6.png (192K) Download Attachment

Bob Arning-2

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

In reply to this post by Hannes Hirzel

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.

timrowledge

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

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computer and car salesmen differ in that the latter know when they are lying.

Bob Arning-2

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

Edgar De Cleene

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

In reply to this post by timrowledge

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?

marcel.taeumel

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. ;-)

Best,

Marcel

Am 05.10.2017 10:47:18 schrieb Edgar J. De Cleene <[hidden email]>:
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" 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?

Hannes Hirzel

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

In reply to this post by Edgar De Cleene

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

Hannes Hirzel

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

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

Hannes Hirzel

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

I have started a new thread covering the topic of the two previous mails.

'About missing services in FileServices initialize'

This thread is about FileList / FileList2
HH

On 10/5/17, H. Hirzel <[hidden email]> wrote:

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

Hannes Hirzel

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

In reply to this post by timrowledge

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.

I assume you mean the model for the FileList/FileList2 tools?

My answer: Yes!

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

Edgar De Cleene

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

In reply to this post by Hannes Hirzel

Ok, my mistake.

On 10/5/17, 06:33, "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

timrowledge

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

In reply to this post by Bob Arning-2

> 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

Nicolas Cellier

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

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)...

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

Hannes Hirzel

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)...

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

Hannes Hirzel

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

And the registration mechanism in FileServices was intended to replace
the one in FileList.

So it is like you buy a new Kenwood and still keep and old blender (or
accessory parts of it) around.

It is a matter of putting old things into the dustbin and moving the
bin out of the house to be emptied.

And active effort is needed to clean up and this is what people do
here all the time. Not a new issue. You have to work on a room by room
or shelf by shelf basis.

The question is what to do so that the cleaning task of FileList /
FileList2 remains manageable.

On 10/5/17, H. Hirzel <[hidden email]> wrote:

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

timrowledge

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

In reply to this post by Nicolas Cellier

> 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 ;)

I fairly often feel like “that would be me” is the answer here.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Braccae illae virides cum subucula rosea et tunica Caledonia-quam elenganter concinnatur! = Those green pants go so well with that pink shirt and the plaid jacket!