tx for the feedback!
On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <hannes.hir...@gmail.com> 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 <ricardo.pacheco.rol...@gmail.com> 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" <stepharo.s...@gmail.com>
>> 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
>>
>
