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