$employee->setSalary(50000);
[download]

$employee->Salary = 50000;
[download]

The whole problem here comes originally from people exposing highly interrelated fields as independently manipulable things when they shouldn't and in that case mutators are wrong. The whole idea is to be able to have invariants that are always true about an object and giving access to individual fields can sometimes allow things outside the object to leave the object in a state where the invariant is no longer true. I totally appreciate that. But sometimes objects have fields that are independent of all other fields and can be twiddled by anyone without breaking an invariant. There are only 2 choices for implementing these - direct field access or mutator and in most languages direct access is bad because it cannot be overridden in the future so you use a mutator.

... what better way is there to ask the object "please update your salary field to $50000" ...

That statement is sidestepping the debate. Why are you setting the salary field to "$50000"? What is the thought process behind it? Why aren't you letting the object do more of the thinking?

Let's explore this situation a little more. I can see three reasons why you would want to set the salary.

1. You just hired someone and are setting their salary.

   This should be done as part of the initial creation of the Employee object. There should be a method that accepts a large number of parameters, presumably named and not positional, and will validate those parameters before accepting them.

2. You just gave someone a raise.

   The object should be handling all the math, not you. You should be calling the giveRaise() method. That method should be able to accept a number or a percentage. That method will do all the bit-fiddling.

3. You just promoted someone.

   The object should be handling this. There should be a givePromotion() method that, as one of its optional parameters, accepts a new salary value. That method will do all the bit-fiddling.

Now, the object enforces the business rules of the HR department. You can't just walk into someone's cube and say "Hey, I decided to set your salary to $50000. Have a nice day!" and expect the HR department to be ok with it. (Depending on the prior salary, the employee might not be ok with it, either!)

I am starting to become convinced that everytime someone says "I need a mutator here!", they're really saying "I haven't fully thought out my problem, but I know I can bruteforce it with a mutator!" I'm not saying that brute force is necessarily a "Bad Plan"™. I am saying that it's not good theoretical practice.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

# You just gave someone a raise. The object should be handling all the math, not you. You should be calling the giveRaise() method. That method should be able to accept a number or a percentage. That method will do all the bit-fiddling.

You forgot demotion and salary decrease, you also forgot a method to make someone's wage 20% more than someone elses and a gazillion other ways of determining someone's new salary.

So bascially I'll say to my manager I'm quitting if you don't pay me 50000 a year, he says OK and now he has to do the math so he can enter the correct increase into the system? Wy can't he just enter 50000 if that's what he wants.

If you're still not convinced, then consider the case where it's not a numeric value, it's an object value and there's no sensible way I can specify the new value as "the old value modified in this fashion". The only option is to just tell the object "here's your new value, forget about the old one". That's a mutator.