StringHolder subclass: FileList?

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

StringHolder subclass: FileList?

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

Reply | Threaded
Open this post in threaded view
|

Re: StringHolder subclass: FileList?

Nicolas Cellier
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.
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.
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.
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.
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).
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 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).

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)




Reply | Threaded
Open this post in threaded view
|

Re: StringHolder subclass: FileList?

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

Reply | Threaded
Open this post in threaded view
|

Re: StringHolder subclass: FileList?

Hannes Hirzel
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 <[hidden email]> wrote:

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