FileList and friends and the insane things they do

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

FileList and friends and the insane things they do

timrowledge
In my seemingly never ending quest to clean out nasty misuse of FileList and descendants and StandardFileMenu etc I keep coming across place where it is clear some serious problems have occurred during the life of the code. Apparently the approach of CASE NIGHTMARE APRICOT has lead to trans-dimensional leakage of deviant bytes from the realms of the Soul Eater.

Let's look at an example or two -

FileList2 class>>#projectOnlySelectionMethod:
This has nothing much to do with actual FileLists; it is a messy way to find files with certain filename extensions. It gets used in contexts completely unrelated to a File List.  FileDirectory>entriesForProjectFiles would probably be a little less obnoxious?

SugarNavigatorBar>>#publishSexp is rather fun, too. I *think* al that messing with the FileList2 instance near the bottom is to remove a button, though since there is also an interaction with the Project>>#storeOnServerInnards code and the interesting usage of #saveLocalOnlyHit and the Preference.

Then there is SugarNavigatorBar class>>#findAnythingMorph. The only findable use relates to putting a non-functional example instance into the 'objects' morph. And QuickGuideGenerator>>#makeInputDirList.

Comments on any known history of why, or what is supposed to happen etc welcomed. They're yet more excellent examples of why some hint of documentation is nice. Sure, code tells you what actually happens, assuming you can actually make any sense of it, but not about what is *meant* to happen, or what is not yet included, or why.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Utinam barbari spatium proprium tuum invadant! = May barbarians invade your personal space!



Reply | Threaded
Open this post in threaded view
|

Re: FileList and friends and the insane things they do

timrowledge
OK, I'm going to take the lack of responses to mean that nobody minds me eviscerating this ugly stuff.

> On 10-03-2018, at 11:31 AM, tim Rowledge <[hidden email]> wrote:
>
> In my seemingly never ending quest to clean out nasty misuse of FileList and descendants and StandardFileMenu etc I keep coming across place where it is clear some serious problems have occurred during the life of the code. Apparently the approach of CASE NIGHTMARE APRICOT has lead to trans-dimensional leakage of deviant bytes from the realms of the Soul Eater.
>
> Let's look at an example or two -
>
> FileList2 class>>#projectOnlySelectionMethod:
> This has nothing much to do with actual FileLists; it is a messy way to find files with certain filename extensions. It gets used in contexts completely unrelated to a File List.  FileDirectory>entriesForProjectFiles would probably be a little less obnoxious?
>
> SugarNavigatorBar>>#publishSexp is rather fun, too. I *think* al that messing with the FileList2 instance near the bottom is to remove a button, though since there is also an interaction with the Project>>#storeOnServerInnards code and the interesting usage of #saveLocalOnlyHit and the Preference.
>
> Then there is SugarNavigatorBar class>>#findAnythingMorph. The only findable use relates to putting a non-functional example instance into the 'objects' morph. And QuickGuideGenerator>>#makeInputDirList.
>
> Comments on any known history of why, or what is supposed to happen etc welcomed. They're yet more excellent examples of why some hint of documentation is nice. Sure, code tells you what actually happens, assuming you can actually make any sense of it, but not about what is *meant* to happen, or what is not yet included, or why.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Utinam barbari spatium proprium tuum invadant! = May barbarians invade your personal space!
>
>
>
>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
There are no stupid questions. But, there are a lot of inquisitive idiots.