Traits instead of presenter about presenter HOT 1 OPEN

Disagreed with this.

Traits are a form of inheritance, so whatever behavior your trait(s) supply should be thought of as attached to the model itself. So this is really the same thing as the model having this method directly.

Magic accessors are a performance issue, and they make for an exceptionally confusing API. Why? Because nowhere on your model or your database will you find a property called "fullName". If you don't know what it's implemented as a magic accessor, you'll be tearing your hair out wondering where the fuck $user->fullname is coming from. It also kills IDE support, AND kills the ability to define interfaces.

Traits which depend on properties of their children inherently couple them to their children, but do not provide a sane mechanism for requiring that their children have that behavior present. Abstract classes exist because they can define a "relationship contract" whereby their children MUST implement methods that they (the abstract class) rely on (e.g. for the template method pattern). But traits have no such mechanism. This means that splitting code out of a class and into a trait is splitting code for the sake of splitting it, and not merely to better encapsulate responsibility.

A better way to handle presenters is via a decorator or a simple formatting class.

$user = new UserPresenter($user);
$user->getFullName();
or

UserPresenter::getFullName($user);

from presenter.