On 12/31/12 4:26 PM, Rico Moorman wrote:
Hello Bob and Mike,
Reading a little within the suggested book I came across the following statement.
We should first examine the merits and limitations of the traditional approach: using functions as a basis for the architecture of software systems. This will not only lead us to appreciate why we need something else — object technology — but also help us avoid, when we do move into the object world, certain methodological pitfalls such as premature operation ordering, which have been known to fool even experienced O-O developers.
Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?
I'm not Bob nor Mike, and haven't read the text in question, but when you encounter "function" in most any imperative or OO setting, it almost certainly means a first-order procedure. No mathematical functions. No higher-order thingamabobs that you can pass to or return from other thingamabobs. Just an address in code with an expected stack frame configuration associated with it. As for learning object orientation, I'd second the suggestion of Smalltalk. I'll leave the religious wars aside, but "OOP" means very different things to very different people. Most people use the term whilst referring to C++ and Java, but most people recognize that the ideological framework is best attained by Smalltalk (and related languages like Ruby). So, if you're interested in learning the ideology, then Smalltalk is a great place to get it. Also, Smalltalk has the "become" method, which is amazing magic. -- Live well, ~wren