New chapter for coming book: Messages

> Looks Great, congratulations!! I just read it and has a couple of mistakes
> in the first figures. The return value of the false (2.3, 2.4).
>
> Regards
> Ricardo
>
> El sept. 11, 2017 12:12 AM, "Stephane Ducasse" <[hidden email]>
> escribió:
>
> Hi
>
> after this crazy esug I took a long bus and I wrote one missing
> chapter for the forhtcoming bus.
> I plan to have a first full version for 1 of October :)
>
> I reorganised and massively clean the book contents.
>
> Comments are welcome in any form.
>
> Stef
>
> https://github.com/SquareBracketAssociates/LearningOOPWithPharo
>

> Hello Stephane
>
> I like the emphasis of the chapter that implementing same selector
> several times at the proper place in a couple of classes is more
> important than to rely on inheritance.
>
> In particular the conclusion
>
> <citation>
> What is important to realise is that classes are cheap. It is better
> to write 5 little classes than a huge one. Some (even smart) people
> got confused by measuring complexity of a system using number of
> classes. Having many classes representing good abstractions with a
> single responsibility is much much better than having a single class
> exhibiting multiple responsibilities.
> </citation>
>
> Suggestion: put it into a 'Note' box.
>
>
>
>
>
> And replace
>
>     'got confused'
>
> with:
>
>    'get confused'
>
>
>
>
>
>
>
> Replace:
>
>     Now the choices can be made over multiple tenth of classes.
>
>     'multiple tenth' is an uncommon expression
>
> Suggestion:
>      Now the choices can be made over dozens of classes.
>
>
>
>
>
>
> However
>     'Sending a message is making a choice!'
> takes the view point of the mechanism which does the late binding.
>
> If I write
>
>      aNode emitHTML: aStream
>
> I do not make the choice. There are different types of nodes and they
> all do the same in the sense that they produce HTML code.
>
> In any case to drive the point home more examples are needed.
>
> The Boolean example is the minimal example and as such is interesting.
> But it is a borderline case which just illustrates that Smalltalk goes
> a long way to implement the object and message pattern consistently.
>
> The Pillar example is fine but too terse.
> For people who already understand the issue just a reference is fine.
> But for people new to the concept of replacing a case statement with a
> class hierarchy it is too short.
>
> Elaborate!
>
>
> E.g. have a diagram for a subset of the hierarchy
>
>         PRObject #(''properties'')
>                 PRDocumentItem #(''counter'')
>                         PRDocumentGroup #(''children'')
>                                 PRDocument #()
>                                 PRHeader #(''level'')
>                                 PRList #()
>                                         PROrderedList #()
>                                         PRUnorderedList #()
>                                 PRParagraph #()
>                                 PRReference #(''reference'' ''parameters'')
>                                         PRFigure #()
>                                 PRSlide #(''title'' ''label'')
>                         PRText #(''text'')'
>
> And show all the emitHTML: messages.
>
>
> And go for a third example, e.g. from Morphic or Bloc
>
>
>     position:
>     extent:
>     color:
>     owner:
>     submorphs:
>     drawOn: aCanvas
>
>
> Meaning of last sentence is not clear.
>
> <citation>
> Remember that when we execute a method (and also write it), one key
> information we get is that the receiver from this class or one of its
> subclasses as we will later.
> <citation>
>
>
> Regards
>
> Hannes
>
> On 9/11/17, Ricardo Pacheco <[hidden email]> wrote:
>> Looks Great, congratulations!! I just read it and has a couple of mistakes
>> in the first figures. The return value of the false (2.3, 2.4).
>>
>> Regards
>> Ricardo
>>
>> El sept. 11, 2017 12:12 AM, "Stephane Ducasse" <[hidden email]>
>> escribió:
>>
>> Hi
>>
>> after this crazy esug I took a long bus and I wrote one missing
>> chapter for the forhtcoming bus.
>> I plan to have a first full version for 1 of October :)
>>
>> I reorganised and massively clean the book contents.
>>
>> Comments are welcome in any form.
>>
>> Stef
>>
>> https://github.com/SquareBracketAssociates/LearningOOPWithPharo
>>
>

> tx for the feedback!
>
>
> On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <[hidden email]> wrote:
>> Hello Stephane
>>
>> I like the emphasis of the chapter that implementing same selector
>> several times at the proper place in a couple of classes is more
>> important than to rely on inheritance.
>>
>> In particular the conclusion
>>
>> <citation>
>> What is important to realise is that classes are cheap. It is better
>> to write 5 little classes than a huge one. Some (even smart) people
>> got confused by measuring complexity of a system using number of
>> classes. Having many classes representing good abstractions with a
>> single responsibility is much much better than having a single class
>> exhibiting multiple responsibilities.
>> </citation>
>>
>> Suggestion: put it into a 'Note' box.
>>
>>
>>
>>
>>
>> And replace
>>
>>     'got confused'
>>
>> with:
>>
>>    'get confused'
>>
>>
>>
>>
>>
>>
>>
>> Replace:
>>
>>     Now the choices can be made over multiple tenth of classes.
>>
>>     'multiple tenth' is an uncommon expression
>>
>> Suggestion:
>>      Now the choices can be made over dozens of classes.
>>
>>
>>
>>
>>
>>
>> However
>>     'Sending a message is making a choice!'
>> takes the view point of the mechanism which does the late binding.
>>
>> If I write
>>
>>      aNode emitHTML: aStream
>>
>> I do not make the choice. There are different types of nodes and they
>> all do the same in the sense that they produce HTML code.
>>
>> In any case to drive the point home more examples are needed.
>>
>> The Boolean example is the minimal example and as such is interesting.
>> But it is a borderline case which just illustrates that Smalltalk goes
>> a long way to implement the object and message pattern consistently.
>>
>> The Pillar example is fine but too terse.
>> For people who already understand the issue just a reference is fine.
>> But for people new to the concept of replacing a case statement with a
>> class hierarchy it is too short.
>>
>> Elaborate!
>>
>>
>> E.g. have a diagram for a subset of the hierarchy
>>
>>         PRObject #(''properties'')
>>                 PRDocumentItem #(''counter'')
>>                         PRDocumentGroup #(''children'')
>>                                 PRDocument #()
>>                                 PRHeader #(''level'')
>>                                 PRList #()
>>                                         PROrderedList #()
>>                                         PRUnorderedList #()
>>                                 PRParagraph #()
>>                                 PRReference #(''reference''
>> ''parameters'')
>>                                         PRFigure #()
>>                                 PRSlide #(''title'' ''label'')
>>                         PRText #(''text'')'
>>
>> And show all the emitHTML: messages.
>>
>>
>> And go for a third example, e.g. from Morphic or Bloc
>>
>>
>>     position:
>>     extent:
>>     color:
>>     owner:
>>     submorphs:
>>     drawOn: aCanvas
>>
>>
>> Meaning of last sentence is not clear.
>>
>> <citation>
>> Remember that when we execute a method (and also write it), one key
>> information we get is that the receiver from this class or one of its
>> subclasses as we will later.
>> <citation>
>>
>>
>> Regards
>>
>> Hannes
>>
>> On 9/11/17, Ricardo Pacheco <[hidden email]> wrote:
>>> Looks Great, congratulations!! I just read it and has a couple of
>>> mistakes
>>> in the first figures. The return value of the false (2.3, 2.4).
>>>
>>> Regards
>>> Ricardo
>>>
>>> El sept. 11, 2017 12:12 AM, "Stephane Ducasse" <[hidden email]>
>>> escribió:
>>>
>>> Hi
>>>
>>> after this crazy esug I took a long bus and I wrote one missing
>>> chapter for the forhtcoming bus.
>>> I plan to have a first full version for 1 of October :)
>>>
>>> I reorganised and massively clean the book contents.
>>>
>>> Comments are welcome in any form.
>>>
>>> Stef
>>>
>>> https://github.com/SquareBracketAssociates/LearningOOPWithPharo
>>>
>>
>
>

> Stephane
>
> Thank you for the reminder in the chapter that classes are cheap!
> If I have a class hierarchy with 300 classes  (for example builder
> classes) but they all implement just one method (#build) then that is
> not complex at all.
>
> Another thing:
>
> I assume you will have a chapter on visitors as well. Do you have an
> outline / draft for that?
>
> --Hannes
>
> On 9/11/17, Stephane Ducasse <[hidden email]> wrote:
>> tx for the feedback!
>>
>>
>> On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <[hidden email]> wrote:
>>> Hello Stephane
>>>
>>> I like the emphasis of the chapter that implementing same selector
>>> several times at the proper place in a couple of classes is more
>>> important than to rely on inheritance.
>>>
>>> In particular the conclusion
>>>
>>> <citation>
>>> What is important to realise is that classes are cheap. It is better
>>> to write 5 little classes than a huge one. Some (even smart) people
>>> got confused by measuring complexity of a system using number of
>>> classes. Having many classes representing good abstractions with a
>>> single responsibility is much much better than having a single class
>>> exhibiting multiple responsibilities.
>>> </citation>
>>>
>>> Suggestion: put it into a 'Note' box.
>>>
>>>
>>>
>>>
>>>
>>> And replace
>>>
>>>     'got confused'
>>>
>>> with:
>>>
>>>    'get confused'
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Replace:
>>>
>>>     Now the choices can be made over multiple tenth of classes.
>>>
>>>     'multiple tenth' is an uncommon expression
>>>
>>> Suggestion:
>>>      Now the choices can be made over dozens of classes.
>>>
>>>
>>>
>>>
>>>
>>>
>>> However
>>>     'Sending a message is making a choice!'
>>> takes the view point of the mechanism which does the late binding.
>>>
>>> If I write
>>>
>>>      aNode emitHTML: aStream
>>>
>>> I do not make the choice. There are different types of nodes and they
>>> all do the same in the sense that they produce HTML code.
>>>
>>> In any case to drive the point home more examples are needed.
>>>
>>> The Boolean example is the minimal example and as such is interesting.
>>> But it is a borderline case which just illustrates that Smalltalk goes
>>> a long way to implement the object and message pattern consistently.
>>>
>>> The Pillar example is fine but too terse.
>>> For people who already understand the issue just a reference is fine.
>>> But for people new to the concept of replacing a case statement with a
>>> class hierarchy it is too short.
>>>
>>> Elaborate!
>>>
>>>
>>> E.g. have a diagram for a subset of the hierarchy
>>>
>>>         PRObject #(''properties'')
>>>                 PRDocumentItem #(''counter'')
>>>                         PRDocumentGroup #(''children'')
>>>                                 PRDocument #()
>>>                                 PRHeader #(''level'')
>>>                                 PRList #()
>>>                                         PROrderedList #()
>>>                                         PRUnorderedList #()
>>>                                 PRParagraph #()
>>>                                 PRReference #(''reference''
>>> ''parameters'')
>>>                                         PRFigure #()
>>>                                 PRSlide #(''title'' ''label'')
>>>                         PRText #(''text'')'
>>>
>>> And show all the emitHTML: messages.
>>>
>>>
>>> And go for a third example, e.g. from Morphic or Bloc
>>>
>>>
>>>     position:
>>>     extent:
>>>     color:
>>>     owner:
>>>     submorphs:
>>>     drawOn: aCanvas
>>>
>>>
>>> Meaning of last sentence is not clear.
>>>
>>> <citation>
>>> Remember that when we execute a method (and also write it), one key
>>> information we get is that the receiver from this class or one of its
>>> subclasses as we will later.
>>> <citation>
>>>
>>>
>>> Regards
>>>
>>> Hannes
>>>
>>> On 9/11/17, Ricardo Pacheco <[hidden email]> wrote:
>>>> Looks Great, congratulations!! I just read it and has a couple of
>>>> mistakes
>>>> in the first figures. The return value of the false (2.3, 2.4).
>>>>
>>>> Regards
>>>> Ricardo
>>>>
>>>> El sept. 11, 2017 12:12 AM, "Stephane Ducasse" <[hidden email]>
>>>> escribió:
>>>>
>>>> Hi
>>>>
>>>> after this crazy esug I took a long bus and I wrote one missing
>>>> chapter for the forhtcoming bus.
>>>> I plan to have a first full version for 1 of October :)
>>>>
>>>> I reorganised and massively clean the book contents.
>>>>
>>>> Comments are welcome in any form.
>>>>
>>>> Stef
>>>>
>>>> https://github.com/SquareBracketAssociates/LearningOOPWithPharo
>>>>
>>>
>>
>>
>