Ridiculous. I hope this guy enjoys the fantasy world he is living in.

If you use accessor methods to pull all the data out of an object, manipulate it, and then put it back in, then you are doing something wrong. Using them to ask for a property so you can display it is totally fine.

Think about a typical situation with a web UI. With his approach you would stick a bunch of HTML in your object (or, possibly even less practical, invent your own layout system on top of HTML). You can't just ask the object to draw itself for input or draw itself for display, because on screen A it is supposed to be in 2 columns and pink, while on screen B they only want to show part of the object's data and it has to be lime green. Web UIs are full of the "multiple views" problem. A simple view layer, like a templating system with a little glue code, solves this problem.

If you want to know how far you will get with the approach he is advocating here, imagine telling your web designer that you can't get the exact layout she designed in Dreamweaver because the objects you designed have to be allowed to do their own rendering.

Look at his arguments against MVC:

In the simple example above, you're tasked with adding an employee ID to every name in every screen that displays employee names. In the RAD-style architecture, you'll have to modify every one of these screens by hand, modifying or adding widgets to accomodate the new ID field.

Doing it his way, you will have no precise control over what the ID field looks like within a screen, and won't be able to do it differently on different screens.

You'll also have to add facilities to the Employee class to be able to set the ID.

If I'm using something like Class::DBI, it will already see that I added this field in the database and automatically create accessors.

And you'll have to examine every class that uses an Employee to ensure that the ID hasn't broken anything.

I'll run my test scripts. He will have to examine every place in the application that this thing shows up to make sure it doesn't look like hell.

For example, comparison of two Employee objects to see if they're equal must now use the ID, so you now have to modify all this code. If you had simply encapsulated the identity into a Name class, none of this work would be necessary. The Name objects would simply display themselves in the new way. Two Name objects would now compare themselves using the ID information; your code that called fred.compareTo(ginger) or fred.equals(ginger) wouldn't have to change at all.

Now he's talking as if MVC meant we don't have classes. Of course we have classes with MVC, and of course we can compare them without asking for all the data through accessors. And I won't bother to comment on the stuff about code generation, since the kind of code generation we use (AUTOLOADS, evals) is done when the program is run.

I could attack the rest of his examples (the ATM thing is also very silly), but I'm sure you get the idea.