Review helpers naming and usage

[samdark]

Review helpers naming and usage

[tomaszkane]

IMHO the suffix makes it clear what it basically is: A namespace for a bunch of static helper functions.

Also thanks to suffix you avoid class name conflict/duplicate, in ex:

use app\models\File;
use app\helpers\FileHelper;

instead of:

use app\models\File;
use app\helpers\File as FileHelper;

[marcelodeandrade]

Could be something like

Helper->get('array')->filter()
Helper->get('file')->createDirectory()

This would put an end to the class name problem with reserved words, concentrating the helper on a single point

[machour]

FileHelper -> File?
ArrayHelper -> ???

Good suggestion from the forum:

• ArrayHelper -> Arrays
• FileHelper -> Files

[schmunk42]

AFAIR you once decided against eg. Array because it's a reserved word in PHP. I don't really favour the plural form over the helper suffix. IMHO the suffix makes it clear what it basically is: A namespace for a bunch of static helper functions.

[tomaszkane]

Could be something like

Helper->get('file')->filter()
Helper->get('array')->createDirectory()

Please no,

1. 'file' and 'array' is "magic" so ours IDE dont't know what to autocomplete here
2. also IDE don't know what is returned by get->() and we have same problem as above

[fcaldarelli]

I'd keep as it is, because when we use them at top, it can be difficult to know what they are.

For example:

use \helpers\File

File::exists(...) 

Now it will be redundant, but it is clearer.

[itma]

I think we should keep the suffix 'Helper' to avoid future conflicts with PHP. What needs to be done is just unifying the names (ArrayHelper vs Url => UrlHelper). The second reason is the readability of that name. Developer immediately know what is the purpose of that class.

[rob006]

You are free to do so, but when working in a team, I think both ways can be problematic, since you need to remember that in one project you have extended Html with foo and in another project with bar.

This will never be a problem if your introduce some basic conventions. If you create contextual helpers for each context (common\helpers\Html, frontend\helpers\Html, backend\helpers\Html, etc) this is super easy - if you're generating frontend specific stuff, you're always using frontend\helpers\Html. It actually make it easier than without own helpers - Yii already has 3 Html helpers (1 in core and 2 in bootstrap packages) - it is easier to remember that "in fronted I'm always using frontend\helpers\Html" than remember which bootstrap package you're using for this app.

If you use those extended helpers in other packages, things are getting worse, since you need to know which File (helper) from which namespace has the method you are looking for

That will be a problem only if you create separate helpers instead of extend basic one. But if you just extend base helper (like yii\helpers\Html) you don't need to think about it, you're always using your own helper (app\helpers\Html) since it contains all methods from parent (yii\helpers\Html) and all custom methods.

[rustamwin]

ArrayHelper -> ???

My suggestion: Arr, Collection

[machour]

@schmunk42 because I don't want to keep remembering that it's Html::fileInput & MyOwnThing::starsInput for example.

I consider a helper to be more a Swiss army knife than a rigid thing that needs to be final, and I rather carry a single one around.

[tomaszkane]

I have my own collection of helpers in all projects and most of it extends Yii2 helpers.
I example: FileHelper has method IsImage().

[rob006]

I mean replacing that @machour described.

For me his example looks more like regular extending (example 1 from my comment).

[machour]

To make it clear, yes, I only do Regular extending, and use that in my own view/files. This should not affect any other extension / core behavior.

Doing replacement (2. in @rob006 example) is asking for troubles.

[schmunk42]

You are free to do so, but when working in a team, I think both ways can be problematic, since you need to remember that in one project you have extended Html with foo and in another project with bar.

But yeah, this is the exact opposite to the point @machour said in #176 (comment)

If you use those extended helpers in other packages, things are getting worse, since you need to know which File (helper) from which namespace has the method you are looking for, ending up in aliasing Helpers when using two with the same name.

[tomaszkane]

Agree with @rob006, in example: I have private composer repository my-company/yii2-helpers and include it in every project - never have compatibility/extending problems - just always use "my" namespace.

[hiqsol]

FileHelper -> File?
ArrayHelper -> ???

[rustamwin]

Would be great, if you are remove Base prefix all helpers

[ancpru]

Would be great, if you are remove Base prefix all helpers

This does not have just advantages. Having a "Base" implementation and an actual final class makes transparent extension possible.

[samdark]

A good question is if the extension needed at all. Helpers usually are quite fundamental and simple.

[schmunk42]

I think the helpers are very useful, I'd like to see them in the core.

[samdark]

I'm not questioning helpers themselves but the need to extend them and naming.

[schmunk42]

I actually never overwrote/extended a Helper with the same name, like you can do it with the base classes. I'd use a separate helper for it.

[samdark]

Did you extend helpers at all? What for?

[schmunk42]

Did you extend helpers at all?

Can't remember a case from the top of my head.

[samdark]

https://forum.yiiframework.com/t/extending-helpers/125477

[itma]

I have my own collection of helpers in all projects and most of it extends Yii2 helpers.
I example: FileHelper has method IsImage().

I think that's the way people are extending helpers. They have built own set basing on delivered by Yii.

[schmunk42]

Why would you need to extend a class only consisting of static functions? Actually there's no need for this.

[samdark]

There is a danger in the ability to extend these. One may modify normal helper behavior causing trouble in both his own project and, what's more interesting, extensions using these methods.

[rob006]

@samdark Could you clarify what dou you mean by "extending"?

1. Regular extending:

namespace app\helpers;

class Html extend \yii\helpers\Html {
   // ...
}

2. Replacing yii\helpers\Html by own implementation:

namespace yii\helpers;

class Html extend \yii\helpers\BaseHtml {
   // ...
}

[samdark]

I mean replacing that @machour described.

[terabytesoftw]

I agree with @rob006 because I did not leave the same convention from yii2 to yii3, there would be less problems when it comes to migration, it is already proven that everything works perfectly, the framework will never prevent programmers from doing bad practices.

[chrisb34]

I agree with @rob006, @tomaszkane and @itma

I regularly extend helpers such as arrayHelper to provide my own functionality. Great idea from @tomaszkane to use a private composer repository though - would save me a lot of time and effort!

I vote for keeping "helper" for reasons of possible contention with PHP in the future using names like Url and Html - look at the hassles with the Object class.

[samdark]

So decisions:

1. Helpers won't be final.
2. Helper remains.