[squeak-dev] StringHolder subclass: FileList?
hannes.hirzel at gmail.com
Thu Oct 5 11:46:24 UTC 2017
as a whole I agree with you that
FileList has a StringHolder (or any other view object displaying
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.
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".
>> 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
>> 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
>> 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
>> surprising to see the litany of *Tool-something in the method categories
> Because a string is such a fundamental thing.
>> That's the easy way to share features between tools, but not the simple
>> (understand simple vs easy like in Rich Hickey's talk
> What would be solution?
>> 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.
>> 2017-10-05 10:43 GMT+02:00 H. Hirzel <hannes.hirzel at gmail.com>:
>>> Tim R. asked about the FileList hierarchy  (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
>>> >> 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 
>>> 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.
>>>  FileList printHierarchy '
>>> ProtoObject #()
>>> Object #()
>>> Model #(''dependents'')
>>> StringHolder #(''contents'')
>>> FileList #(''fileName'' ''directory''
>>> ''volList'' ''volListIndex''
>>> ''list'' ''listIndex''
>>> ''pattern'' ''sortMode''
>>> ''brevityState'' ''directoryCache''
>>> FileChooser #(''view''
>>> ''caption'' ''captionMorph'' ''captionBox''
>>> ''cancelButton'' ''okButton'' ''buttonPane''
>>> ''captionPane'' ''directoryPane''
>>> ''filePane'' ''showShortFileNames'')
>>> PluggableFileList #(''accepted''
>>> ''fileFilterBlock'' ''canAcceptBlock''
>>> ''validateBlock'' ''newFiles'' ''prompt'' ''resultBlo
>>>  FileList in Pharo6:
>>> ProtoObject #()
>>> Object #()
>>> Model #(#dependents #announceur)
>>> FileList #(#reference #volumeList
>>> #list #listIndex
>>> #pattern #brevityState #dirSelectionBlock #modalView #ok #contents
>>> #optionalButtonSpecs #grid #fileEncoding #sortBlock #baseLabel
>>> #configuredServices #sourceTextModel)
More information about the Squeak-dev