Introduction to OOP for UPBE was: Some new book chapters :)
I would like the opinion of the community on this. I have discussed the addition of an introduction to OOP back when I was very actively contributing to UPBE and the response I got was very positive. The plan was similar to what I mentioned, just bare basics , making sure that the reader understand the very basic fundamental concepts of OO, like classes, inheritance, instances, class and instance variables, class and instance methods etc. Essentially a chapter similar to my video tutorials but going a bit deepers with more detailed example still keeping it simple , clear and understandable even for non coders. I want to know whether such chapter would be included because I dont like to waste my time or the precious time of the student that has taken the task on her shoulders. "IMHO this is the exception to that obvious rule. OOP in particular is misunderstood by almost everyone. If we as Smalltalkers describe it from a forensic CS perspective that sounds to me like C++, I believe it is better that we say nothing on the subject." Personally I dont care if people misunderstand OOP , I only care about getting my code to work the way I want it. So far I had no problem doing that even though I code using very simple concept some of them may come even back when I was coding in C++. I also dont share the sense of wonder that some of you may share about how Smalltalk is doing OO, coming from python does not seem such a big deal for me. For example message passing suppose to be this super powerful feature , that diffirentiate from method calls in the essence that the user does not need to know the internals of the class. But I have not seen a class that take advantage of this feature inside pharo. In every single case if I had exchanged the message passing with method calls I would not have even noticed the difference. In every case I have studied each message corresponds to a method with exactly the same name. I am sure maybe one day will come handly , but I dont see why one needs to explain a feature that rarely someone will use understand how to code in a specific environment.
Le 29/03/2015 15:18, kilon alios a écrit :
For example message passing suppose to be this super powerful feature , that diffirentiate from method calls in the essence that the user does not need to know the internals of the class. But I have not seen a class that take advantage of this feature inside pharo. In every single case if I had exchanged the message passing with method calls I would not have even noticed the difference. In every case I have studied each message corresponds to a method with exactly the same name. I am sure maybe one day will come handly , but I dont see why one needs to explain a feature that rarely someone will use understand how to code in a specific environment.
Hello, You may really take a look at the *first* paragraph of Alan Lovejoy's article mentioned in my previous message, and pass it to the student as well: http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.ht... Without this understanding, one fails to understand why #ifTrue: argument is a block, or why #and: message's argument is a block[] surrounded by parenthesis(), then the beginner may have a hard time to use correctly the class libraries. Best, -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Not really because those concepts are already explained in other chapters. Blocks and conditions and why conditions are the way they are are explained in Chapter 3. Chapter 4 explains messages in general including the use of parentheses , how messages are sent , the different kind of messages , when to use a block and when to use parentheses, cascades etc etc. Chapter 5 explains the model system of Pharo, method lookup , self sends, super sends and much more. So the chapter we are writing will go between Chapter 4 and 5 and offer a smoother introduction to OO. The focus is to offer a practical approach to the very fundamentals with as little overlap as possible with other chapters. Part II of PBE goes deeper also, chapter 13 covers classes and metclasses in great detail, Chapter 14 which is about Reflection describes method dictionaries , accessing run time context, intercepting MNUs etc. Stef once also published a very detailed chapter on Blocks with many advanced features . This used to be in Pharo for the Enterprise , now should be in PharoInProgress. And yes I understand how messages work. The iink your provided is a reference documentation and I dont like this kind of documentation sinking inside theory with few practical examples. Quite the opposite of PBE and frankly a really bad way to teach coding especially to a newcomer and someone unfamiliar with OOP. On Sun, Mar 29, 2015 at 5:17 PM, Hilaire <hilaire@drgeo.eu> wrote:
Le 29/03/2015 15:18, kilon alios a écrit :
For example message passing suppose to be this super powerful feature , that diffirentiate from method calls in the essence that the user does not need to know the internals of the class. But I have not seen a class that take advantage of this feature inside pharo. In every single case if I had exchanged the message passing with method calls I would not have even noticed the difference. In every case I have studied each message corresponds to a method with exactly the same name. I am sure maybe one day will come handly , but I dont see why one needs to explain a feature that rarely someone will use understand how to code in a specific environment.
Hello,
You may really take a look at the *first* paragraph of Alan Lovejoy's article mentioned in my previous message, and pass it to the student as well:
http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.ht...
Without this understanding, one fails to understand why #ifTrue: argument is a block, or why #and: message's argument is a block[] surrounded by parenthesis(), then the beginner may have a hard time to use correctly the class libraries.
Best,
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Hello, [..] no need to list the chapters, I know the book. Le 29/03/2015 16:43, kilon alios a écrit :
The iink your provided is a reference documentation and I dont like this kind of documentation sinking inside theory with few practical examples. Quite the opposite of PBE and frankly a really bad way to teach coding especially to a newcomer and someone unfamiliar with OOP.
We are probably not reading the same article then, the one I pointed to you comes with a lot of examples. Nevertheless, only its first paragraphs were of interest related to the point Sean raised. Anyway I gave my opinion and will stop on this discussion before it overheats. Best -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
first example is at page 5 . I don't overheat , I rarely get angry. So there is no reason to worry, all opinions are more than welcomed. If the styles of documentation that the community desires is on par with the link you provided then I know and this is not what I want to be working on. But since creating a chapter is quite an effort I rather spent efforts on things that are here to stay than things that get ignored. its ok , chapter cancelled, I hope an expert is found sometime in the near future to fill in our shoes. Have fun :) On Sun, Mar 29, 2015 at 5:59 PM, Hilaire <hilaire@drgeo.eu> wrote:
Hello,
[..] no need to list the chapters, I know the book.
Le 29/03/2015 16:43, kilon alios a écrit :
The iink your provided is a reference documentation and I dont like this kind of documentation sinking inside theory with few practical examples. Quite the opposite of PBE and frankly a really bad way to teach coding especially to a newcomer and someone unfamiliar with OOP.
We are probably not reading the same article then, the one I pointed to you comes with a lot of examples. Nevertheless, only its first paragraphs were of interest related to the point Sean raised. Anyway I gave my opinion and will stop on this discussion before it overheats.
Best
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
I would like the opinion of the community on this. I have discussed the addition of an introduction to OOP back when I was very actively contributing to UPBE and the response I got was very positive. The plan was similar to what I mentioned, just bare basics , making sure that the reader understand the very basic fundamental concepts of OO, like classes, inheritance, instances, class and instance variables, class and instance methods etc. Essentially a chapter similar to my video tutorials but going a bit deepers with more detailed example still keeping it simple , clear and understandable even for non coders.
If you write something I will review it and tell you if it is ok for the book. If this is more or less ok, I'm ready to do a pass. so I can help if what you write is ok. Now I do not know your writing skills so I do not want to tell you that this is ok without even getting a feel about what you can produce.
I want to know whether such chapter would be included because I dont like to waste my time or the precious time of the student that has taken the task on her shoulders.
"IMHO this is the exception to that obvious rule. OOP in particular is misunderstood by almost everyone. If we as Smalltalkers describe it from a forensic CS perspective that sounds to me like C++, I believe it is better that we say nothing on the subject."
Personally I dont care if people misunderstand OOP , I only care about getting my code to work the way I want it. So far I had no problem doing that even though I code using very simple concept some of them may come even back when I was coding in C++. I also dont share the sense of wonder that some of you may share about how Smalltalk is doing OO, coming from python does not seem such a big deal for me.
For example message passing suppose to be this super powerful feature , that diffirentiate from method calls in the essence that the user does not need to know the internals of the class. But I have not seen a class that take advantage of this feature inside pharo.
sorry but I do not get the last paragraph. To me method calls are just a different way to call message passing and I prefer message passing because it conveys that we do not directly refer to the method but that the method is dynamically selected.
In every single case if I had exchanged the message passing with method calls I would not have even noticed the difference.
How could you? in Smalltalk the only to implement what you call method calls is to access directly the method and use executeXXX on it.
In every case I have studied each message corresponds to a method with exactly the same name.
There are plenty of methods defined with the same name in the system so I do not get your point.
I am sure maybe one day will come handly , but I dont see why one needs to explain a feature that rarely someone will use understand how to code in a specific environment.
??? Stef
participants (3)
-
Hilaire -
kilon alios -
stepharo