Object Oriented Programming - Revision history

JaroslavTulach: /* Revolutionary view */

JaroslavTulach — Wed, 15 Apr 2026 07:51:08 GMT

Revolutionary view

←Older revision		Revision as of 07:51, 15 April 2026
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 calls]!	+	The above characteristic of [[OOP]] leads to an interesting conclussion: [[OOP]] needs [https://web.archive.org/web/20110716163344/https://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]].
-

	=== [[SuperVsInner\|Object Oriented Reuse]] ===		=== [[SuperVsInner\|Object Oriented Reuse]] ===

JaroslavTulach: /* Object Oriented Reuse */

JaroslavTulach — Sat, 24 Sep 2022 05:49:20 GMT

Object Oriented Reuse

←Older revision		Revision as of 05:49, 24 September 2022
Line 16:		Line 16:


-	=== Object Oriented Reuse ===	+	=== [[SuperVsInner\|Object Oriented Reuse]] ===

	{{:SuperVsInner}}		{{:SuperVsInner}}

JaroslavTulach: /* Revolutionary view */

JaroslavTulach — Wed, 24 Feb 2010 07:34:34 GMT

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 */

JaroslavTulach — Sun, 07 Feb 2010 08:40:53 GMT

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

JaroslavTulach — Sun, 07 Feb 2010 08:37:41 GMT

←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 */

JaroslavTulach — Sat, 28 Nov 2009 16:48:42 GMT

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 */

JaroslavTulach — Wed, 04 Nov 2009 06:01:50 GMT

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 */

JaroslavTulach — Tue, 03 Nov 2009 08:23:22 GMT

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 */

JaroslavTulach — Tue, 03 Nov 2009 08:22:10 GMT

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 */

JaroslavTulach — Tue, 03 Nov 2009 08:16:49 GMT

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 ===