Re: [Pharo-users] 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" <stepharo.self@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
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.roldan@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.self@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
tx for the feedback! On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <hannes.hirzel@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.roldan@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.self@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
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 <stepharo.self@gmail.com> wrote:
tx for the feedback!
On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <hannes.hirzel@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.roldan@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.self@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
For the Visitor chapter it is in preparation... (first I should finish the lecture schedule and after do another pass on the first book ) it will be an extension of the Expression chapter On Sat, Sep 16, 2017 at 1:53 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
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 <stepharo.self@gmail.com> wrote:
tx for the feedback!
On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <hannes.hirzel@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.roldan@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.self@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
participants (3)
-
H. Hirzel -
Ricardo Pacheco -
Stephane Ducasse