Let's use the "shapes" example, to see what OOP's big mistakes are:

In Erlang:
  -module(shapes).
  -export([area/1]).
  area({rectangle,X,Y}) -> X*Y;
  area({circle,R})  -> R*R*3.14.
In Ruby:
  class Rectangle
	def initialize(x,y)
	   @x = x
	   @y = y
	end
	def area
	   @x*@y
	end
  end
  class Circle
	def initialize(r)
	   @r = r
	end
	def area
	    ''''''3.14*(@r**2)
	end
  end
Let's say I want to add perimiter/circumference to the shapes.  In the Ruby example, I have to do this: 
  class Circle
	def perim
	    ''''''2*3.14*@r
	end
  end
  class Rectangle
	def perim
	   2*(@x+@y)
	end
  end
It would be worse in JavaLanguage because you would have to open up the code.

In Erlang:
  -module(shapes2). 
  -export([perim/1]).
  perim({circle,R}) -> 2*3.14*R;
  perim({rectangle,X,Y}) -> X+Y+X+Y.
If Erlang did not require modules, it would be even better.
Which changes more, Features or Shapes?  In most domains the answer would be Features.

STATE IS THE ROOT OF ALL EVIL.

State is a bad thing for 3 reasons:
	1. state makes concurrency difficult
	2. it makes reasoning about code difficult
	3. it increases coupling.
Hidden State is doubly bad.  It makes code that looks fine act strangely when you are mutating state, and you can't figure it out because you can't access the variable(s).

----

Note that I did NOT create this topic nor write any of the above. --top

''LOL!  Defensive much?  Well, I can't say I don't understand why... I can ''sooo'' see you being accused of it, except that you're generally better at presenting your thoughts than whoever wrote the above.  Your request is duly noted.''

''I think the author of this document has some sort of frustrations but hasn't a clue how to communicate them.  Does he wish to KillMutableState?  Or does he just object to the concept that 'circles' and 'squares' should be considered objects instead of geometric values.  Personally, I agree on the latter, but I recognize that these circles and squares are useful for education.'' --db