" x.sin "

Good point. I guess in C++ numbers aren't objects so you can't do this.

I hope they understand that this is just an exercise. I have seen too often these things being elevated into a religion.

> I have seen too often these things being elevated into a religion.

Yeap. I have no hard preference between sin(x) or x.sin, in an OOP context or not, as long as the language is somewhat consistent (e.g., it bothers me that Ruby has some of these functions on the numbers themselves, like 1.23.floor, but others live on Math, like Math.sin(42)).

> it bothers me that Ruby has some of these functions on the numbers themselves, like 1.23.floor, but others live on Math, like Math.sin(42)).

Every time I type `len(some_list)` in Python, I die a little inside.

While I agree to an extent, the reason for this is not entirely bad. The len function is basically a contract that the result you get will be an integer. An object could easily have a `.length` property that is non-integer, like a line/interval for instance. Think of this as a clunky response to a lack of type information in the language proper.

> Nitpick, but why "m = new Math() s = m.sin(x)" would be "the OOP way" instead of "x.sin" ?

Because you can't do the latter post-hoc. You can't add hyperbolic functions by yourself if your standard library didn't anticipate them. Well, in Ruby you can and it's a standard practice to pollute this way classes at random, and in Python you can as well, though it's frowned upon, but certainly you cannot in C++ or Java.

it's probably doable as is in Smalltalk, the issue is OOP trying to ontologically categorize everything is impossible; one day we may need operations on numbers we don't know now and we'll have to "import CategoricalHomotopy as ch; ch.tropos(42)"