Sometimes an object is exactly the right tool. Also it makes the syntax nice and clear: xyz->foo() is sometimes much clearer than foo(xyz). But yes, wrapping any bit of data into a object is silly. Some things are just not objects. Others make for very awkward objects. My personal favorite is a result of an SQL query that JOINs multiple tables. Do you make each type of joon its own type or do you just dynamically extend the existing type a la JavaScript? I tend to do the latter but that does not work well in a lot of languages and goes against their intent at best.
Lastly, OOP need != class based inheritance. Thus JavaScript is a very viable OOP environment any is very widely used, so no OOP is by no means dead.
Comments
Sometimes an object is exactly the right tool. Also it makes the syntax nice and clear: xyz->foo() is sometimes much clearer than foo(xyz). But yes, wrapping any bit of data into a object is silly. Some things are just not objects. Others make for very awkward objects. My personal favorite is a result of an SQL query that JOINs multiple tables. Do you make each type of joon its own type or do you just dynamically extend the existing type a la JavaScript? I tend to do the latter but that does not work well in a lot of languages and goes against their intent at best.
Lastly, OOP need != class based inheritance. Thus JavaScript is a very viable OOP environment any is very widely used, so no OOP is by no means dead.