Nicolas,

as a whole I agree with you that

    FileList has a StringHolder (or any other view object displaying
file contents)

is preferred to

    FileList is a StringHolder

So if Tim rewrites this I have no objection  .....

Part of the problem probably is is that the ToolBuilder transition
could not be finished because of unresolved issues around.

--Hannes

On 10/5/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> On 10/5/17, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>> Concerning StringHolder, that's the classical "is a" versus "has a".
> Yes.
>
>> A FileList is a special kind of StringHolder (the file contents -
>> presumably bytes interpreted with some encoding) with many gadget for
>> switching the content.
>
>> A FileList is a tool for inspecting directories and files and has a Text
>> pane for viewing interpreted file contents (or why not another with raw
>> code in hexadecimal, etc...).
>>
>
>> Of course "is a" kind of work, but sounds like a very partial POV, unless
>> all files are text files.
>
> Look at the example of showing an image file. You get the meta
> information of the file.
> Image size plus a preview (thumbnail) of the image.
>
>
>> IMo it's an abuse of inheritance.
>
>
>
>> Moreover, StringHolder has hooks for
>> selectedMessageName/selectedClassName,
>> and many action for Smalltalk code.
>> So the name does not really tells what it is, it's a model for holding
>> Smalltalk snippet/code.
>
> The classical Smalltalk way is that every text may be evaluated as
> code. So nothing wrong with having a Smalltalk snippet / code.
>
>> If we want a model for holding text without evaluation nor navigation
>> capabilities, then we have to undo in sublcass the default behaviour of
>> super class.
>
> No, we do not want this. It is good that code may be evaluated.
>
>> Also note that #selectedClass is implemented in Model, though it is
>> mostly
>> for text panes, it's strange to find such hook at such high level.
>
> Yes. We need to describe what StringHolder does.
> Could you Nicolas or somebody else please commit my contribution
> (preferably with some extension)
>
> The Inbox: Kernel-hjh.1115.mcz
>
>
>> This kind of model aggregates all possible features of tools, and it's
>> not
>> surprising to see the litany of *Tool-something in the method categories
>> (protocols).
>
> Because a string is such a fundamental thing.
>
>> That's the easy way to share features between tools, but not the simple
>> way
>> (understand simple vs easy like in Rich Hickey's talk
>
> What would be solution?
>
>> https://www.infoq.com/presentations/Simple-Made-Easy).
>
>
>> So I perfectly understand the will of Pharo to sanitize a bit the code
>> (separate concerns, modularize, encapsulate).
>
> Yes, some good points there.
> If I read the Pharo code -- not everything is better. Just different.
>
> --Hannes
>
>> 2017-10-05 10:43 GMT+02:00 H. Hirzel <hannes.hirzel at gmail.com>:
>>
>>> Hello
>>>
>>> Tim R. asked  about the FileList hierarchy [1] (see
>>> FileList2>listForPattern(s): and MessageSend abuse thread)
>>>
>>> On 10/4/17 9:27 PM, tim Rowledge wrote:
>>>
>>> >>    Don’t suppose you recall anything about why it is subclassed from
>>> StringHolder?
>>> >>    That really does seem odd...
>>>
>>> Bob A:
>>> >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.
>>>
>>> Pharo directly subclasses Model [2]
>>>
>>> I think the current solution of subclassing StringHolder is OK.
>>>
>>> Interesting to note that if you select an image file in the file list
>>> you get the dimensions of the image file plus a thumbnail view of it.
>>> Very nice.
>>>
>>> I agree that a complete rewrite of FileList (and subclasses) is a
>>> worthwhile thing to do.
>>>
>>> Regards
>>> Hannes
>>>
>>>
>>> [1] FileList printHierarchy '
>>> ProtoObject #()
>>>         Object #()
>>>                 Model #(''dependents'')
>>>                         StringHolder #(''contents'')
>>>                                 FileList #(''fileName'' ''directory''
>>> ''volList'' ''volListIndex''
>>> ''list'' ''listIndex''
>>>                                               ''pattern'' ''sortMode''
>>> ''brevityState'' ''directoryCache''
>>>                                                ''lastGraphicsExtent'')
>>>                                         FileList2
>>> #(''showDirsInFileList''
>>> ''currentDirectorySelected''
>>>                                                ''fileSelectionBlock''
>>> ''dirSelectionBlock''
>>>                                                ''optionalButtonSpecs''
>>> ''modalView''
>>>                                                ''directoryChangeBlock''
>>> ''ok'')
>>>                                                 FileChooser #(''view''
>>> ''caption'' ''captionMorph'' ''captionBox''
>>>
>>> ''cancelButton'' ''okButton'' ''buttonPane''
>>>
>>> ''captionPane'' ''directoryPane''
>>>
>>> ''filePane'' ''showShortFileNames'')
>>>                                         PluggableFileList #(''accepted''
>>> ''fileFilterBlock'' ''canAcceptBlock''
>>>
>>> ''validateBlock'' ''newFiles'' ''prompt'' ''resultBlo
>>>
>>>
>>> [2] FileList in Pharo6:
>>>     ProtoObject #()
>>>         Object #()
>>>                 Model #(#dependents #announceur)
>>>                         FileList #(#reference #volumeList
>>> #volumeListIndex
>>> #list #listIndex
>>> #pattern #brevityState #dirSelectionBlock #modalView #ok #contents
>>> #optionalButtonSpecs #grid #fileEncoding #sortBlock #baseLabel
>>> #configuredServices #sourceTextModel)
>>>
>>>
>>
>