Comments 19
Не хватает пояснений, зачем в 2025 году писать собственный автозагрузчик, если уже есть PSR-4
Например если это внутренний проект компании где нужно свести использование библиотек к 0, и не зависеть от composer
Автозагрузчик можно сгенерировать на этапе сборки. Было бы полезно раскрыть, какие именно ограничения мешают использовать стандартный PSR-4?
Хорошо, я не хочу генерить, хочу знать в коде каждый символ. Разве это плохо? И чем это противоречит PSR? Если я использую стандартную функцию языка для этого? В фреймворках думаете копировать, вставить?
PSR это стандарт, который как раз и нужен, чтобы код был предсказуемым и совместимым, даже внутри компании.
Никто не мешает «знать каждый символ». Composer и другие автозагрузчики имеют открытый код, изучай сколько хочешь. Зачем изобретать велосипед, если стандартное решение уже работает и не противоречит Вашему подходу?
Зачем мне его изучать, если я могу написать свою, на это буквально уходит от нескольких минут до рабочего дня. И все знать, и иметь её под свою структуру? Меня вот лично очень пугают языки которые навязывают код своей структурой, например int main в c++. Мне кажется про то что вы говорите, это больше про навязывание кода. Я считаю что использую стандарт за счет встроенной функции.
То есть PSR-4 «навязывает», а своя кастомная схема — нет? Написать свой автозагрузчик — не проблема, вопрос в том, зачем. Удобство, поддержка и совместимость важнее желания «всё знать». Можно и свой HTTP-сервер на сокетах поднять, но почему-то все используют Nginx.
Скрытый текст
А так все мы через это проходили, когда были джунами — такой огромный мир, и так хочется переписать его под себя! Но чем больше опыта, тем яснее: вместо того, чтобы изобретать велосипед, проще взять готовый и тратить время на написание кода, который реально решает проблемы, а не создает новые.
Можно, конечно, гордиться своим автозагрузчиком, но это как строить свою машину, потому что «не хочу изучать, как работает заводской двигатель». Главное, не забыть потом написать свой компилятор и TCP/IP-стек — вдруг C++ тоже что-то «навязывает».
Вы мне пытаетесь сказать что моя кастомность это потомучто я не так инклюд написал? А использование специальной функции языка, это как-бы ничего не значит? Мне совместимость как раз таки и не нужна, в коде нет библиотек, и фреймворк из него выпиливается (там и не компосер, и не копировать, вставить, а своя реализация, тоже через функцию языка).
То есть, если вам «совместимость не нужна», то стандартные решения уже не имеют смысла? Логика железная! Тогда зачем вообще PHP? Напишите свой язык — так точно будете знать каждый символ. А если серьезно, то reinvent the wheel — классическая стадия. Пройдет.
На среднем распределение, слева от центра и справа пишут свое, (для какого-то человека, все эти PSR, самописный код). Очень важно одно с другим не перепутать, вы мне все предлагаете что-то реализовать, но то что вы предлагаете не влияет на мою структуру папок веб приложения, логику подключения (вплоть до логирования) и всего того что мне нужно в моей архитектуре, большие вещи написаны, они классные, я ими пользуюсь.
Представим будущее. Ваш проект разросся, и вдруг понадобилось переиспользовать модули в другом проекте. Или вы устроились в компанию, где люди уже используют Composer. И тут вопрос: будете писать еще один кастомный загрузчик для своих же библиотек? Или вручную инклюдить их по всему коду? А если решите объединить их в свой фреймворк, то что, напишете свой пакетный менеджер?
С такими темпами, глядишь, через пару лет дойдете до своего интерпретатора PHP, чтобы вообще ничего «не навязывало». Главное, чтобы потом не пришлось объяснять новому поколению разработчиков, почему ваш код живет в параллельной вселенной, где стандарты — это зло.
Есть разработчики которые прямо сейчас развивают достаточно неплохой фреймворк на своём ответвлении PHP. (Вконтакте?) И што?)
Информация за 20-какой год? ВКонтакте, как и все старые PHP-компании, давно переходит на Go. Их KittenPHP был нужен не ради кастомного автозагрузчика, а для трансляции кода в C++ ради производительности. Так что ваш пример как раз подтверждает, что изобретать свой велосипед в 2025 году — это больше про хобби, чем про реальную необходимость.
А я и не про ВК :)
Любопытный пример, но хотелось бы больше — поделитесь закулисьем индустрии! Какие еще компании в 2025 году массово отказываются от стандартов в пользу кастомных решений? Было бы интересно посмотреть реальные кейсы, где это дает объективное преимущество, а не просто «мне так удобнее».
P.S.
Это мой последний комментарий, увы, времени на эту дискуссию больше нет. Напомню лишь, что стандарты не просто так появились — бизнесу важна предсказуемость. Проще и быстрее найти специалиста, который умеет работать с общепринятым инструментом, чем тратить время и деньги на обучение его вашей уникальной системе.
Мы тут все, конечно, профессионалы, но в итоге нам нужно решать задачи, а не бесконечно рефакторить автозагрузчик. Продакшен требует проверенных решений, которые работают предсказуемо и масштабируемо, а не самописного кода ради самописного кода.
не понятно чем composer не угодил можно ведь в нем сделать загрузку с приватных репо или локальных файлов
стандартный универсальный инструмент
вы можете это реализовать и при этом не зависеть от composer (что чрезвычайно странно и не нужно, проект, вероятно ужасен внутренне)
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-examples.md
и стандарт к которому все привыкли, будете соблюдать, и внешние библиотеки не будете подгружать
В комментариях к статье, на которую далась ссылка вам уже все рассказали про стандарты, паттерны и вот это вот все. Здесь вы опять пытаетесь рассказать всему PHP сообществу, как на самом деле нужно жить.
Грусть
А потом люди из других языков смотрят на это и думают что PHP говно.
Клиентский код. Пространство имен