В последнее время с талкиваюсь с всё частым обращением к __autoload()
Но в тоже время появилось два противоположных мнения: или очень положительное или очень отрицательное. Именно нейтральных не особо много.

Вот и хотелось бы узнать, что такого "хорошего" и что такого "плохого" в этой __autoload()? Ну или проще, использовать ли мне это в своих проектах?

Я отрицательно к ней отношусь: нельзя несколько функций назначить.

Положительно отношусь к spl_autoload_register и не вижу ни одной причины ее не использовать.

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

Absinthe не согласен из любой ситуации есть выход.

а как это всё же правильнее использовать (лучше на примере)?

Даже из ситуации, когда подключаемый к сайту сервис сам устанавливает __autoload ?

spl_autoload_register вместо __autoload просят применять даже на php.net. Нужна ли простому php-шнику ещё какая-то рекомендация?

т.е. я по идее могу забыть о своих способах подключения классов и использовать это?

Да. Если нет необходимости поддерживать php-4, то нет никакого смысла не использовать встроенные в язык средства.

ну а в чём же её приимущества по сравнению с самописными средствами?

Gold Dragon, в том что тебе дается нативная поддержка автозагрузки, то есть достаточно написать так:

 Учи матчасть, ты просто не понял, что я написал.

 http://php.net/spl_autoload_register

 В том, что на публичном хостинге работать будет, а полноценные самописные средства нет, т.к. придется самому компилировать. Потому что нельзя полноценный аналог написать не в виде сишного расширения.
Ну и еще в том, что написание аналогов стандартных функций всегда считается ###кодом, т.к. всегда ухудшает читаемость и поддержку кода.

Не согласен, так как нужно исходить из задачи и требований, на хабре по моему была статейка где описывалась как раз такая ситуация, где нативное решение пришлось заменить своим.

Не будь хамом плиз.

Это сообщение отредактировал(а) krundetz - 19.1.2012, 13:18

 Аргументируй в контексте данной задачи.

 Я не хамил. Нахамить я хочу лишь персонажу "супервладислав", но я его игнорирую - пока получается.

Просто поясню с чем я не согласен. А именно со словом всегда, вот в этом предложение:

В контексте же задачи топика безусловно это не оправдано.

ну значиться я не понял.

 Слово "аналог" однозначно и не допускает двоякого толкования. Прямо как наличие экстремизма в  Ветхом Завете.
Если что-то имеет дополнительный функционал - то это уже не аналог.

Вообщето многие опытные программисты и разработчики вроде Макконнелла и т.д.(специализирующиеся по "чистому коду") очень рекомендуют задавать явное подключение и разброс подключений по функциям, файлам и тем более классам крайне не желателен. Я согласен впринципе с ними, так как если поддержку, или чего хуже расширение системы, проводит сторонний разработчик или группа разработчиков (да ещё с более низкой специализацией) автолоад может несолько усложнить понимание архитектуры. Всегда желательно явная архитектура особенно в подключаемых файлах. Мало того фактически подключение ведётся в зависимости от абстракции, то есть в индексном файле - окружение, в фабриках - определённые классы абстракций, а использовать функцию для отдельного аспекта как то не резон, лучше всё таки определить это место явно впереди инстанцирования или в индексном файле.

При различных видах подключений файлов определённых абстракций приходится обрабатывать ошибки по своему иногда, автолоад является универсальной и не даёт той гибкости, ещё один момент. 

Это сообщение отредактировал(а) Sentox - 19.1.2012, 23:54

spl_autoload_register вызывается только тогда класс не объявлен и при обращении к конкретному классу если он его не находит...

так же как и __autoload()

 Цитату из Макконела, пожалуйста.

 В реалиях PHP данные фразы противоречат друг другу. Либо разбросать подключения, либо сделать автоподключение.

 Каким же образом? Да даже не усложнить, а просто повлиять на понимание? Любая IDE сама разберется, где какой файл подключается.

 И что? Посмотри, как автозагрузка работает.

 Зачем?

 Каким же образом? Да даже не усложнить, а просто повлиять на понимание? Любая IDE сама разберется, где какой файл подключается.

[/QUOTE]
Честно говоря не хочется вступать в дискусию (всё таки это холивар чистой воды будет  ).
У Макконнелла, если кто внимательно читал, всё "пропитано" простотой архитектуры и построения и если что то задаётся неявно и можно сделать проще - это нужно сделать. По поводу цитаты - можете сами у Макконнелла да и не только у него найти - пишите для людей (программистов) а не для IDE, да так что бы можно было читать код и не искать где производится включение кода (особенно если касается разработчиков работающих не с IDE (не будем разводить холивар что пора бы уже перебраться на них)). Это меня наводит на программистов на JS, которые пишут имена переменных и функций наподобие "btcdret", как говорится - повбывав бы )

Я бы сказал дискусия на тему _autoload() подобна применению директивы goto, так же неявно задаёт смысл читаемого кода.
Без цитат -   Макконнелл и его сторонники рекомендуют - прямолинейное "чтение" кода упрощает разработку и особенно  поддержку его последующими разработчиками.

Так же есть затруднение с переносимостью модулей (допустим модулей). При архитектруе фасад и фабрики мы могли бы модуль полностью сделать автономным, при "доверении" подключаемых файлов в __autoload мы лишаемся, некторой части автономности, а детальней при переносе в другой проект он уже потребует сторонних включений своих!!! же файлов, то есть мы перенесём знания структуры модуля во внешнюю структуру ... судите сами 

Это сообщение отредактировал(а) Sentox - 20.1.2012, 22:54

Sentox, если я правильно понимаю назначание __autoload то это в превую очередь исключение дублирующих include и require, а eже потом все остальное

Это сообщение отредактировал(а) krundetz - 20.1.2012, 23:16

Исключение дублирующих include и require - это include_once и require_once (при чём на уровне пхп машины!) всё остальное не должно это надстраивать если это уже до нас сделали.

Можно на эту тему? Кто в фасаде и фабрике расскажет фабрике где находятся модули?
Не будет ли более корректно отвязать фабрику и фасад от информации о структуре файлов модуля и оставить им только собственную логику? Не повысит ли такая отвязка автономность модуля?

Фактически фасад я упомянул так, для универсальности (скажем так пример модуля компилятора с фасадом к модулю (извините за тавталогию)), а вот фабрика может сама "знать" о с своей структуре и подключать файлы (хотя бы в switch (кстати хороший пример абстрактная фабрика, которая "отрывает" модуль от платформо - зависмости)). Допустим имеем одну фабрику (файл), который является так же и инфраструкторой модуля. При подключении одного файла - фабрики мы включаем в работу весь модуль не отдавая "знаний" включения его структурных файлов, а алгоритм использования модуля лежать может на интерфейсах фасада.

Впринципе это моё мнение.

Добавлено @ 23:39

Фасад наверное да, скорее всего, а вот фабрика как раз и призвана локализировать по определённой категории, аспекту или абстракции инстанцирование и подключение объектов. Так что её алгоритм основной как раз в этом и состоит.

Добавлено через 12 минут и 33 секунды
Наверное и скорее всего _autoload будет применим к конкретному аспекту подключения основных скриптов ядра системы, хотя честно говоря я не сторонник этого, несколько безответственно даёт разработчикам вносить включения классов, и если система будет раздуваться это грозит сложностями.

Это сообщение отредактировал(а) Sentox - 20.1.2012, 23:40

Sentox, ТОесть, что свалить в одну кучу ДВА РАЗНЫХ механизма ( файловую структура модуля и фабричную логику) будет более правильно с точки зрения ООП, чем сделать 2 независимых друг от друга механизма? 

Начнём с первого:
к ООП это точно не относится ,  (не люблю не аргументированных ответов) - так как ООП (как программирование так и проектирование) структурирует в основном (да ну в основном) данные и призвано к качественному манипулированию данными, но с инфраструтурой лучше справляется именно функциональные решения, поэтому вся инфраструктура может определена в одном методе (функции)

Второе:
вопросом на вопрос - в чём состоит суть фабрики (не абстрактной фабрики), и как лучше разделить аспекты подключения файловой структуры модуля и инстанциирование объектов из классов модуля?

Это сообщение отредактировал(а) Sentox - 21.1.2012, 00:24

Спрашивая о "не абстрактной фабрике" стоит ее как то определить, не так ли? Фабрика, вообще говоря по символическому обозначению предоставляет некий конкретный объект. К примеру, по запросу "дай мне класс для отправки почты", в зависимости от конфигурации приложения и состояния сервера может выдать класс, основанный на mail, smtp или еще какой почтовой приблуде... Фабрика обязана знать КАК инициировать все эти разные классы, однако не обязана знать ГДЕ конкретно они находятся.

Вообще говоря, все разговоры вокруг ООП и стиля программирования обязаны приводить к удобству повторного использования кода. При повторном использовании такой фабрики, в приложении с другой файловой организацией, но с тем-же примерно комплектом серв-объектов, не придется переписывать ее вообще.

Как же Вы не поймёте что файовая организация модуля локальна для модуля и соответственно фабрики.


Да нет же, я ж писал выше, она является ещё и инфраструктурой, если хотите index.php для модуля (компонента).
И ещё как должна знать, если она "хочет" быть инфраструктурой модуля и единственной знающей единицей о структуре..

Всё же мой вопрос в силе? Я просто могу пример привести что при выходе "знаний" структуры наружу рушится целостность автономности.

Это сообщение отредактировал(а) Sentox - 21.1.2012, 02:05

 Именно поэтому я за автозагрузку. Наиболее прямой и простой метод без дублирования. В данном случае автозагрузка дает простую иерархическую архитектуру модулей и единую точку подключения.

 Какой части автономности ты лишаешься?

 Ей знать не надо, она может просто нужное подключать и оно подключится. spl_autoload_register();

 Именно. Эти данные уже есть в архитектуре приложения и при написании их в явном виде происходит дублирование.
Это то же самое, что применение {} скобок: синтаксический анализатор заставляет их использовать по традиции, хотя в явном виде они ему не нужны. И уж тем более не нужны разработчику, т.к. для него код в первую очередь размечен отступами, а не кодом.

но ведь интепретатору нужно предприянять действия отсеевающие дубли? а так вроде бы один вызов одно подключение.

Хотелось бы увидеть.

так.. Я совсем запутался в этих рассуждениях. Можно чуть ближе к "земле"? 

допустим, у меня есть ядро. где-то там я делаю функция


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


Т.е. при появлении new произойдёт вызов функции __autoload в которую передастся переменная  ClassName(). Ну и соответственно в самой функции подключается файл  _PATH . $class_name . '.php'
Так?

я так понимаю, что основной спор возникает при условии что если кто-то в одном из подключаемых модулей пожелает также сделать свою такую же функцию? Так?

И ещё, что будет если в коде будут встречаться отдельно ?
include_once _PATH . $class_name . '.php';

Так.

Так. Для того, чтобы иметь таки возможность вставить в свой модуль свой автолод  php.net рекомендует использовать spl_autoload_register - более гибкий аналог .

Ничего плохого. Если инклуд встетился ДО использования класса - автолод не будет вызван для загрузки этого класса, причем, если класс и не пригодится для работы приложения - он все равно окажется описан. Если после - еще раз тикнет процедура проверки include_once. 

Просто с автолодом можно вообще НИГДЕ не использовать инклуды.

тогда дальше.. Из мануала я так толком и не понял как воспользоваться spl_autoload_register и как он вообще функционирует.. Поясните на простом примере.

и Второе, если встретится два spl_autoload_register что произойдёт и какой будет исполнен? или такого не может (не должно) быть?

Нужно написать функцию, которая выглядит и работает как __autoloaad, но называется по другому. и вызвать spl_autoload_register с параметром - именем этой функции. 



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

то есть так?

а подключать так?

или как-то по другому?




Это сообщение отредактировал(а) Gold Dragon - 21.1.2012, 11:42

http://ru.php.net/manual/ru/function.spl-a...ad-register.php
там дофига примеров. Что конкретно не понятно?
http://ru.php.net/manual/ru/function.spl-a...ister.php#95456
Вот наиболее простой пример, а все остальные рассказывают чем этот способ лучше простого автолода 

ksnk, напиши пожалуйста пример на основе моего (самый верхний пост на этой странице ;) никак не могу ухватить суть с этими параметрами...


Это сообщение отредактировал(а) Gold Dragon - 21.1.2012, 14:00

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

ВСЁ!!! теперь понял 
Ну я примерно так и думал, что нужно через spl_autoload_register инициализировать функцию которая будет обрабатывать подключение. А дальше при new всё будет происходить автоматом

тогда ещё один вопрос. Что будет при: 
?

Добавлено через 2 минуты и 17 секунд
и ещё. Из мануала пример, но не смог правильно перевести с инглиш

Что произойдёт и что будет вызиваться?

выведет. 

а про ещё один вопрос


раньше я где-то подключал файл и потом где угодно использовал ::
А сейчас это автоматом подключится или мне в любом случае хоть раз но нужно сделать

?

да, работает

ksnk, огромное спасибо за человеческие объяснения ;)

В общем теперь всё понятно что и как. Ну и соответственно понятно что лучше использовать в своих проектах

Gold Dragon, интересная статьтя http://habrahabr.ru/blogs/php/136761/

MoLeX, спасибо. отличная статья для понимая ;)