JaroslavTulach: /* Revolutionary view */ - 2010-02-24 07:34:34

Revolutionary view

←Older revision Revision as of 07:34, 24 February 2010
Line 14: Line 14:
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].
 +
 +
 +
=== Object Oriented Reuse ===
 +
 +
{{:SuperVsInner}}
=== History ===
=== History ===

JaroslavTulach: /* Revolutionary view */ - 2010-02-07 08:40:53

Revolutionary view

←Older revision Revision as of 08:40, 7 February 2010
Line 11: Line 11:
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type
-
The above characteristic of [[OOP]] leads to an interesting conclussion: [[OOP]] needs [http://projectfortress.sun.com/Projects/Community/blog/ObjectOrientedTailRecursion tail recursion]!
+
The above characteristic of [[OOP]] leads to an interesting conclussion: [[OOP]] needs [http://projectfortress.sun.com/Projects/Community/blog/ObjectOrientedTailRecursion tail calls]!
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].

JaroslavTulach at 08:37, 7 February 2010 - 2010-02-07 08:37:41

←Older revision Revision as of 08:37, 7 February 2010
Line 10: Line 10:
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only by calling their methods (sending them messages)
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only by calling their methods (sending them messages)
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type
 +
 +
The above characteristic of [[OOP]] leads to an interesting conclussion: [[OOP]] needs [http://projectfortress.sun.com/Projects/Community/blog/ObjectOrientedTailRecursion tail recursion]!
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].

JaroslavTulach: /* Revolutionary view */ - 2009-11-28 16:48:42

Revolutionary view

←Older revision Revision as of 16:48, 28 November 2009
Line 5: Line 5:
Let me point you to [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf an essay] explaining [[OOP]] in completely revolutionary view. I especially like statements like:
Let me point you to [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf an essay] explaining [[OOP]] in completely revolutionary view. I especially like statements like:
* ''Typical object oriented program relies on functions more than many functional programs.''
* ''Typical object oriented program relies on functions more than many functional programs.''
-
* ''λ-calculus was the first [[OOP]] language''
+
* ''[[λ-calculus]] was the first [[OOP]] language''
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:

JaroslavTulach: /* Revolutionary view */ - 2009-11-04 06:01:50

Revolutionary view

←Older revision Revision as of 06:01, 4 November 2009
Line 8: Line 8:
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:
-
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only calling their methods (sending them messages)
+
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only by calling their methods (sending them messages)
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type

JaroslavTulach: /* History */ - 2009-11-03 08:23:22

History

←Older revision Revision as of 08:23, 3 November 2009
Line 17: Line 17:
[[OOP]] is no longer what it used to be. Somehow the original great visions diluted and instead we have ''class''/''object''/''inheritance'' as present in [[Java]] and other [[OOP]] languages of these days. The daily experience we have with these languages is so strong, so defining that we sometimes tend to forget that the roots of [[OOP]] used to be driven by visions and not technical concepts.
[[OOP]] is no longer what it used to be. Somehow the original great visions diluted and instead we have ''class''/''object''/''inheritance'' as present in [[Java]] and other [[OOP]] languages of these days. The daily experience we have with these languages is so strong, so defining that we sometimes tend to forget that the roots of [[OOP]] used to be driven by visions and not technical concepts.
-
I was reminded about that recently when I read [http://www.artima.com/articles/dci_vision.html Motivation for DCI] at artima website. Just few quotes:
+
I was reminded about that recently when I read [[DCI]] introduction [http://www.artima.com/articles/dci_vision.html paper] at artima website. Just few quotes:
:''Object oriented programming grew out as vision of the computer''
:''Object oriented programming grew out as vision of the computer''

JaroslavTulach: /* Revolutionary view */ - 2009-11-03 08:22:10

Revolutionary view

←Older revision Revision as of 08:22, 3 November 2009
Line 9: Line 9:
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only calling their methods (sending them messages)
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only calling their methods (sending them messages)
-
* In functional world (when using algebraic types) the person that defines a type can inspects and rely on internals of all instances of the same type
+
* In functional world (when using algebraic types) the person that defines a type can inspect internals of all instances of the same type
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].

JaroslavTulach: /* Revolutionary view */ - 2009-11-03 08:16:49

Revolutionary view

←Older revision Revision as of 08:16, 3 November 2009
Line 11: Line 11:
* In functional world (when using algebraic types) the person that defines a type can inspects and rely on internals of all instances of the same type
* In functional world (when using algebraic types) the person that defines a type can inspects and rely on internals of all instances of the same type
-
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [Chapter 18|Extensible Visitor Pattern Case Study].
+
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [[Chapter 18|Extensible Visitor Pattern Case Study]].
=== History ===
=== History ===

JaroslavTulach at 08:02, 3 November 2009 - 2009-11-03 08:02:55

←Older revision Revision as of 08:02, 3 November 2009
Line 1: Line 1:
This is my personal take on [[OOP]]. In case you are searching for objective view, then rather see official [[wikipedia::Object_oriented_programming|wikipedia's explanation]].
This is my personal take on [[OOP]]. In case you are searching for objective view, then rather see official [[wikipedia::Object_oriented_programming|wikipedia's explanation]].
 +
 +
=== Revolutionary view ===
 +
 +
Let me point you to [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf an essay] explaining [[OOP]] in completely revolutionary view. I especially like statements like:
 +
* ''Typical object oriented program relies on functions more than many functional programs.''
 +
* ''λ-calculus was the first [[OOP]] language''
 +
 +
Excellent explanation of the differences between [[OOP]] approach and the ''functional'' one can be summarized into:
 +
* In classical [[OOP]] one only knows own identity. Identity (and implementation) of others can be inspected only calling their methods (sending them messages)
 +
* In functional world (when using algebraic types) the person that defines a type can inspects and rely on internals of all instances of the same type
 +
 +
Last but not least the [http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf essay] mentions the [[expression problem]] which I also analysed in [[TheAPIBook]]'s chapter 18: [Chapter 18|Extensible Visitor Pattern Case Study].
=== History ===
=== History ===

JaroslavTulach: /* History */ - 2009-04-03 14:18:50

History

←Older revision Revision as of 14:18, 3 April 2009
Line 9: Line 9:
:''Object oriented programming grew out as vision of the computer''
:''Object oriented programming grew out as vision of the computer''
:''as an extension of the human mind.''
:''as an extension of the human mind.''
 +
 +
Wow! Really? Makes sense, but this is a piece of wisdom lost for a long time, am I right? Even when I learned about [[OOP]] I heard more the explanation describing the methodology as inspired by nature. The inheritance was the most natural way to define base class ''Mammal'' and subclasses ''Cat'' and ''Dog''.
 +
 +
Our brain can definitely capture more complex concepts than the ''mammal'' example, so maybe, if we want to stick with the old definition, the meaning of [[OOP]] shall be expanded. Definitely beyond the expressive capabilities of [[C]]++ and [[Java]].
:''MVC's goal was to provide the illusion of a direct connection''
:''MVC's goal was to provide the illusion of a direct connection''
:''from the end user brain to the computer "brain"''
:''from the end user brain to the computer "brain"''
 +
 +
:''a large method that represented an entire algorithm was believed to''
:''a large method that represented an entire algorithm was believed to''