StringHolder subclass: FileList?

> 2017-10-05 10:43 GMT+02:00 H. Hirzel <[hidden email]>:
>
>> 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)
>>
>>
>

> On 10/5/17, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:
>>
>>> 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)
>>>
>>>
>>
>