ну такое извращение точно не надо. потом ни одно IDE нормально не покажет, где используются классы

да и назвать я хочу как мне душе угодно

Такое извращение используется во многих местах в фреймворке и позволяет добиться гибкости без нужды редактировать каждый раз карту

В ларе немного иначе, если речь о менеджерах
Там динамически генерируются названия методов менеджера, который создают объект

+

А сами классы могут при этом иметь любое название

Это таже конвенция

а подскажите ссылочку чтобы понимать контекст конвенции

не знаком с данным термином

Динамическая геренация названия чего угодно, метода, класса, функции на основании какой-то строки.

типа whereStatus(1)  where('status', 1)?

https://github.com/alexeymezenin/laravel-best-practices
Тут багато цікавого

Не думаю что это специфический для разработки термин, обычно в сообществе говорят "naming convention", т.е. какое-то соглашение по наименованию.

Допустим тот кейс о котором говорит Илья выглядит примерно так:

В конфигах у нас указывается драйвер для обработки кеша строкой с маленькой буквы: redis, memcached, file.

Мы определяем, что методы для создания драйвера будут называться в формате create{DriverName}Driver - в скобки я выделил то что будет меняться в зависимости от значения в конфиге, т.е. createRedisDrver, createMemcachedDriver ...

А дальше логика примерно такая:

$method = 'create' . Str::studly(config('cache.default')) . 'Driver'
$driver = $cache->$method;

это не так )

Это в целом тоже конвенция

держусь подальше от такой магии и другим по рукам даю

$method = 'create' . Str::studly(config('cache.default')) . 'Driver'
$driver = $cache->$method;

спасибо. стало понятнее

не, я противник любой магии

Ещё пример конвении аксессоры и мутаторы - https://laravel.com/docs/master/eloquent-mutators#accessors-and-mutators

Магії місце в хогвардсі