Extending helpers

[thefsb (Fsb)]

Would that be a big loss if we’ll mark all helpers as final and remove base classes?

Yes it would.

EDIT: Later in the day I realized there would be no BC break because I wouldn’t use Yii 3 except in a completely new project and in that case I can probably adapt to whatever the framework constraints are.

[thefsb (Fsb)]

BTW - I also don’t see benefit to make ANY framework class final.

1. Much less maintenance burden. You can freely use private properties.
2. No creative ways of extending a class. Don’t have to take care about extension points that were not designed to be extendable.
3. final forces using composition instead of inheritance. That’s usually a good thing. Makes code less fragile.

In 1. is “you” the framework author?

I don’t understand 2. And cui bono?

How would you suggest using composition instead of…?

class HtmlPurifier extends \yii\helpers\HtmlPurifier
{
    const CONFIG = ['blah' => 'blah'];

    public static function process($content, $config = null)
    {
        return parent::process($content, self::CONFIG + (is_array($config) ? $config : []));
    }
}

[samdark (Alexander Makarov)]

1. Yes.
2. Again, framework authors. That is a bit more control about framework users endless creativity.

class HtmlPurifier
{
    const CONFIG = ['blah' => 'blah'];

    public static function process($content, $config = null)
    {
        return \yii\helpers\HtmlPurifier::process($content, self::CONFIG + (is_array($config) ? $config : []));
    }
}

But the composition part wasn’t really about helpers but about non-static classes.

[vanhelvzla (Wilmer Arambula)]

I wonder it would not be easier to separate all helpers from the framework as a separate component ?

[AndreasP]

How would that make a difference?

But what about another approach: Implement the helpers as trait. This way a final “custom” helper implementation could be composed.