Андрей159Когда функция в функции, то нужно дважды объявить. Во внешней функции и во внутренней. Иначе никак.Ну почему сразу "никак"? Можно использовать для хранения/передачи данных любой суперглобальный массив. Оно всяко понятнее "глобализации".

ИМХО если подходить с точки зрения парадигмы функционального программирования, то global есть банальный костыль. Без него вполне можно обойтись, передавая переменную по ссылке через параметр вызова функции.

Андрей159API Google, Facebook, VK, OK, Instagram освоите - это только один из 10 нужных пунктиков.Для сшибания бабла - возможно, будет где-то полезным. Для понимания и наработки опыта как программисту в классическом понимании - почти никакой пользы. Это как купить в магазине полочку и прибить ее парой гвоздей к стене. Полочка будет в доме, конечно, но создавать ее Вы не умеете. Конечно, я не призываю всех всё делать руками. Кому-то нравится и галочки в Битриксе тыкать.

полудухvkleИМХО если подходить с точки зрения парадигмы функционального программирования, то global есть банальный костыль. Без него вполне можно обойтись, передавая переменную по ссылке через параметр вызова функции.
в его случае вызов файла идёт ИЗ функции, так что там этот номер не пройдёт, если хочется именно глобальную переменную.В данном случае в наличии имеется банальнейший бардак. А именно, растусовка элементов одной сущности по разным сущностям другого рода. Конкретно, функция перестала быть единым целым и разошлась по разным файлам. Не криминально, но и код весьма не очевиден для понимания. Вот попытка собрать паззл, да ещё и не понимая, как работает штатный сборщик паззлов, окончилась неудачей. Сомневаюсь, что при рассматриваемом подходе костыль в виде второго глобала принесет какую-то практическую пользу.

Если уж очень хочется иметь динамически изменяющуюся функцию и при этом по какой-то причине категорически не хочется использовать ООП, то совсем не обязательно городить огород с инклюдами, можно посмотреть на лямбда-функции, они же, анонимные. Можно, наконец, хоть из кусочков по ситуации сконструячить функцию как текст и eval'нуть его.

полудухДля таких случаев были придуманы классы, которые в умелых руках творят чудесаНаверно, Вам повезло с умелыми руками. Не нарывались на классы, где в метод передается с десяток параметров? А когда какие-нить классы Catalog, Categories, Basket наследуется прямиком от Database, а тот, в свою очередь, от Settings... что хотел сказать автор методом select_all() - поди ж угадай сразу, что оно возвращает массив всех записей по SQL-запросу, а вовсе не полный список товаров в корзине... Жаловались на "не работает периодически" - когда разбираться стал, вышло, что скрипт по нескольку соединений к базе открывает и упирается в лимит для пользователя СУБД когда на сайт народ набегает.

В общем, чего хотел сказать то. Когда в голове каша - любую технологию испоганить можно так, что порой проще переписать кусок с нуля, чем поддерживать как есть. И классы в том числе.

полудухКстати, если будет вереница ф-й, то в каждую кидать эту переменную (а их ведь может быть несколько) вызовет жгучую больНу как сказать... Мое сугубо личное мнение, конечно. Чтоб изолировать от основного скрипта такие вот переменные для прямой передачи из одной функции в другую, вполне можно использовать суперглобальный массив $GLOBALS. Там отдельные массивы "по темам". Конечно, его элементы и применяемость следует расписать где-то в доке, чтоб не нарваться на неприятности. Вряд ли порекомендую этот способ для разработки с нуля, но для поддержки чего-то старенького вполне годится.

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

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

полудухЧем проще метод, тем лучше. 1-3 -строчные методы в идеале.Да ну! И что в эти 1-3 строчки запихаете - вызов функии, с кучей параметров и реализацией бизнес-логики на пару страниц кода?

полудухчтобы метод выполнял 1 задачу, а не винегрет выдавалБанальная, вроде, задача: проверить данные с формы перед записью в базу, сформировать при необходимости список ошибок. Метод изначально пустой, переопределяется в зависимости от конечного класса (клиент, проект, таск, лог, контакт и т.п.), где необходимо проверять от одного до более десятка параметров. В ряде случаев необходимо свериться со смежными сущностями. Например, дата планового окончания таска не должна превышать дату завершения проекта, а дата окончания субтаска (таковой определяется по данным в поле task_parent), соответственно, финальную дату родительского таска.
Есть винегрет? На мой взгляд, нету. А кода до пары страниц в зависимости от.
Вы как-то это распихаете в означенные Вами строчки?

полудухну во1, формы всё-таки стоит разбивать на табы (именно в бэкенде, а не в таблице. Таблица одна), чтобы юзер засылал кусочек, а не все 80 полейПри чем тут табы? Юзер уже все поля заполнил, их значения очищены от возможного мусора и сохранены в экземпляре класса как свойства. Настало время проверки данных.

полудухНапример, "сравнение дат" производится в Date::cmp_two($date1, $date2).Ну а даты откуда возьмутся? Одна пришла из формы, это понятно. Вторая - ?

полудухя пишу так:



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

полудухvkleПри чем тут табы?при том, что вам не нужно обрабатывать 80 полей за раз, а лишь 10.Речь идет о сущности в целом, а не об отдельных полях.

полудухНу это же ваш пример. Найдите там себе свою вторую дату:
авторНапример, дата планового окончания таска не должна превышать дату завершения проекта , а дата окончания субтаска (таковой определяется по данным в поле task_parent), соответственно, финальную дату родительского таска .Именно. Ключевое слово "найдите". Т.е. вымутить еще несколько строк кода для создания экземпляра сущности, загрузки в объект данных с заданным айди из базы, и только тогда искомая дата станет доступна. Четвертой только строчкой можно приступить к сравнению, пятой сформировать ошибку. Удачи Вам в Ваших трехстрочных методах! Мы уж, как-нибудь, по рабоче-крестьянски.


полудухвам видимо показалось, что я здесь чтобы спорить с вами об очевидных вещах )Нет. Просто я не приемлю код-лапшу. Глаза, знаете-ли, устают от него. :)

полудух,

Речь идет о валидации объекта с множеством данных. Метод check() должен вернуть либо "годен", либо "найдены ошибки". Ни больше и не меньше. Мы совершенно о разных о разных вещах говорим, очевидно.
Продолжайте думать о формах, если Вам так угодно.

полудух,

Пока что Вы пытаетесь кому-то что-то доказать, притом, почему-то не в тему. Такое обычно бывает у политиков, когда по делу сказать им нечего.