Почему PHP код с замыканием не работает?

Question

[Григорий Васильков]

Это связано с особенностью PHP или может StdClass просто не позволяет делать такие трюки? Или просто 5.6 не умеет так? (пс. пробую писать в js нотации)

$obj = new StdClass();
  $obj->fn = new StdClass();
  $obj->fn->move = function ($a, $b) {
    print_r($this);
    return $a * $b;
  };
  print_r($obj->fn->move(1,2));

Fatal error: Call to undefined method stdClass::move() in [file] on line [line]

Comments

[Григорий Васильков]

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

[Mikhail Osher]

Вообще-то, в этом коде нет замыкания. Почитайте хотя бы, что это такое.

[Григорий Васильков]

Да ты что! Что ж из тебя так знания прут в демонстративном стиле. Наличие use() которое замыкает переменную для тебя настолько критично чтобы показать свою осведомленность в вопросе?

[Юрий]

Григорий Васильков: "имена классов и неймспейсы равные пути до файла - дибилизм"
никто не заставляет делать их равными. можете хоть 50 классов в один файл положить и у каждого свой неймспейс еще добавить, это все можно, просто на вас будут косо смотреть и показывать пальцем.

посмотрел бы я на вас если бы вы писали сложную систему с тысячами разных классов. если их делать StdClass - то вы просто заноете.

[Григорий Васильков]

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

[Григорий Васильков]

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

Answer 1

[Юрий]

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

UPD: только лишь в спортивных целях покажу как может работать

$f = $obj->fn->move;
  print_r($f(1,2));

то есть функция все таки сохраняется. но новый метод у класса не добавляется.

Comments

[Григорий Васильков]

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

Я еще не проверил, но наверное проще для понимания написать экземпляр, который будет наследоваться, а фактически работать с объектами этого класса, и организовать в нем зависимости раз, слушателя - два и фабрику три, чем каждый раз обьявлять новый класс для контроллера и долбаться где здесь parent:: а где static:: и еще вопрос что на самом деле "человеческий" подход

[Григорий Васильков]

Ну то есть создавая новый контроллер мне по сути без надобности создавать новый класс, мне просто нужны несколько новых методов в обьекте уже существующего контроллера, это и рождает проблему NS которой в JS нету и не было никогда

[Илья Караваев]

Григорий Васильков: Вы уверены, что Вам нужно ООП? В PHP более чем приятно писать и обычные функции...

[Юрий]

Григорий Васильков: в пхп все эти возможности не с потолка взяли. это все есть и во многих компилируемых языках например с++, c#, java. у всех одно и тоже, проблема не в пхп, просто нужно больше практиковаться.
обьектов из js это по сути php массив. а вы взяли вметсо массива StdClass и пытаетесь его так же использовать.
никто не заставляет вас делать все эти "статику, абстракцию, трейт, интерфейс, наследника и потомка". не нужно наследование - не делайте, но создать нормальный именованный клас гораздо удобнее, он будет отлично работать и для этого не нужно использовать(даже знать) ни одно слово из тех что вы перечислили.

[Григорий Васильков]

Юрий: Может и так. Но сама идея создавать PagesDbIndexController чтобы создаеть его синглтон потом это дибилизм. Все что нужно - это Class Controller, который потом расшириться двумя-тремя методами, писать для этого класс (говоря языком природы - создать ВИД, который имеет всего одно существо) - это капец. Капец всех нормальных языков.

[Юрий]

Григорий Васильков: никаких проблем NS никогда не было. вас никто не заставляет добавлять NS, они добавлены лишь для удобства.

[Юрий]

Григорий Васильков: не совсем понимаю чтио вы хотите но уверен на 100% вы делаете чтото не так.
новичкам крайне не рекомендовал бы писать свои фреймворки, особенно если нет четкого понимания что такое класс и основные методы работы с ними.

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

[Григорий Васильков]

Ну да, сначала были длинные имена классов, которые надоело писать потому что классы тупо повторялись, потом их разложили по папкам и сделали совпадение имени класса пути к файлу, а потом надоело писать длинные имена для 10-уровневой вложенности каталогов, и придумали NS которые повторяют те же самые пути и создают ту же проблему но наоборот - теперь мы можем подключать сразу несколько классов, называя это зависимостями не через autoloader и наследование, а просто указывая сверху use.

Внимание, в JS require file.js возвращает обьект-образец, по образу и подобию которого можно создать еще, вызвав New. Проблемы где он лежит нет вообще и никаких неймспейсов не надо - просто подрубил три файла и вот они доступны.

Разве что... вы хотите подрубать сразу 100 файлов, таким образом создавая неймспейс, чтобы написать use и по итогу подрубить сразу 101+ класс, но с такой сложностью я не сталкивался, думаю дебажить этот САЙТ будет адом и зарплатой в пару штук баксов. Впрочем, если это цель, то это верный путь

[Юрий]

Григорий Васильков: все таки не могу понять вашей проблемы. с класами все просто и логично, просто вам надо почитать/посомтреть что-то и понять как они работают.
то что вы контролллеры синглтонами делаете - это явно уже попахивает.
что вы хотите синглтонами там добится? синглтоны удобны тем чтобы иметь во время выполнения ровно один экземпляр класса, (то есть случайно не создать два) и иметь к нему быстрый доступ из любого места кода.
вообще говоря когда то была мода но них, изза простоты, но синглтоны вообще стоит избегать, потому что если будете писать тесты то еще отхлебнете с ними.

[Григорий Васильков]

Не ну синглтоны я не имею в виду Controller::get() - я имею в виду что при создании обьекта он закидывается в массив в классе App а при повторном вызове вызывается снова. Но просто повторного вызова того же контроллера ну точно не будет.

[Григорий Васильков]

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

[Юрий]

Григорий Васильков:
контроллеры выглядят очень просто, во многих фреймворках это класс имеющий список методов - actions

вот пара примеров
https://github.com/symfony/symfony-demo/blob/maste...
https://github.com/symfony/symfony-demo/blob/maste...

"повторного вызова того же контроллера ну точно не будет"
это не причина делать из него синглтон, если вы паритесь из-за этого.

[Григорий Васильков]

Как таковые неймспейсы решают проблемы избыточных имен, источником которой является избыточное количество классов там где на самом деле нужны просто обьекты, обученные методам. То есть мы создаем класс "почтальон" и делаем почтальона, вместо того чтобы создать класс человек и научить его разносить почту.
А потом офигеваем от количества классов в программе - потому они и дублируются, может это и правильно конечно, но проблемы безусловно создает, проблемы избытка информации в голове

[Григорий Васильков]

В примерах из симфони я больше всего люблю это:
namespace AppBundle\Controller;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;

namespace AppBundle\Controller;
use AppBundle\Entity\Comment;
use AppBundle\Entity\Post;
use AppBundle\Events;
use AppBundle\Form\CommentType;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Cache;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Security;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\EventDispatcher\GenericEvent;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

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

[Юрий]

Григорий Васильков: "мне задалбывает их переименовывать постоянно при переносе из одной папки в другую по мере проектирования"
PHPStorm рефакторинг делает сам (shift + F6).

[Григорий Васильков]

Все, теперь понял откуда ноги растут.

[Юрий]

Григорий Васильков: по поводу симфони все просто на самом деле.
если возьмем ноду то такая же простыня будет из require, только require нужно писать руками да еще названия придумывать, а use заполняет IDE, о них вообще забываешь, современный код не пишется в блокноте.

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

[Григорий Васильков]

А вот где суть! IDE сама прописывает зависимости... надо обмозговать, это интереснее чем писать $this->load->controller() каждый раз и $this->load->library

[Юрий]

Григорий Васильков: "Как таковые неймспейсы решают проблемы избыточных имен, источником которой является избыточное количество классов там где на самом деле нужны просто обьекты, обученные методам."
вас же никто не завтсавляет пользоваться ООП подходом, пхп испокон веков работает и процедурный стиль. если вы не понимаете ООП, то зачем себя так мучать. ООП могут использовать только те кому они реально нужны.

вы делаете из себя жертву какую то, но никто вас не заставляет ей быть ;)
пишите процедурно, можно даже как в ноде все сделать впринципе.
ваша попытка использовать StdClass это и есть впринципе процедурный подход, просто вы зря классы выбрали, я уже писал что в пхп обычные массивы это аналоги js обьектов - используйте их и не парьтесь.

[Юрий]

Григорий Васильков: я уже запутался в нашей беседе, вопросы то в верху появляются то внизу. )))

[Григорий Васильков]

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

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

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

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

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

[Юрий]

Григорий Васильков: Григорий, понял ваш ход мыслей.

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

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

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

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

вы сейчас пишите свой фреймворк или какой то базовый код, незнаю что там у вас. а представьте вы заболеете, умрете, или просто уйдете, то кто будет поддерживать ваш код? если там будет код как вы написали выше - то только ненормальные. поэтому фреймворк это и более качественный код, протестированный, документированный.

если вы пишите мелкий

[Юрий]

Григорий Васильков: если вы пишите мелкий одноразовый проект, типа сделал и забыл - то все ок, но если какой то боле менее средний проект, то своего работодателя вы подставляете дважды. во первых беря деньги за написание ненужного ему фреймворка, во вторых привязываете себя к этому проекту до его конца.

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

[Юрий]

Григорий Васильков: итого более высокие зп тех кто пишет на фреймворках это ни разу не маркетинг, а повышение шансов того что
1) проект будет доделан (то есть вы не сольетесь когда поймете что дохрена всего наделали а новые требования не укладываются в вашу концепцию, а переделывать слишком долго)
2) сделан быстро (без лишней работы)
3) стандартизированно (понятно другим программистам)

[Григорий Васильков]

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

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

[Юрий]

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

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

в любом случае удачи вам.

[Григорий Васильков]

ага, и вам туда же

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

[Юрий]

Григорий Васильков: я вам искренне желаю удачи. я не считаю вас противником который где то там от меня по ту сторону баррикад.
просто сейчас в вас я себя узнал лет 5 назад. если вспомнить также думал и говорил. То что я сейчас писал, это отчасти я писал как бы себе в прошлом. хотя конечно и понимаю что бесполезно было бы ;)

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

и по второму пункту, вы преполагаете что мне тогда просто не повезло, а вам повезет.

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

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

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

вот например ссылочка https://toster.ru/answer?answer_id=950627 тут я наоборот агетирую за то что фреймворки это не всегда хорошо. и что есть случаи когда надо писать свой фреймворк. но я убежден что новые фреймворки можно уже писать когда основтаельно порабоатл с чужими и осознал их плюсы и минусы. а когда плюхаешься в ООП, то перспективы туманны.

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

[Юрий]

Григорий Васильков: причем меня там реально считали за хейтера фреймов . весьма символично в том топике в мой адрес писали:

OnYourLips
Юрий: написать свой фреймворк гораздо проще, чем изучить, как работает чужой.

(вот оказывается какой я двуличный) ;)))

[Григорий Васильков]

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

[Юрий]

Григорий Васильков: знаю, понимаю, не отговариваю. просто пилите дальше свой, да набирайтесь опыта. остальное придет.

[Юрий]

Григорий Васильков: именно это и значит мой фраза "когда нибудь поймете". это не понты и не к тому что вы обязаны все сейчас взять и бросить и начать с фрейма с нуля. а к тому что реально надо время, чтобы все это прочувствовать, в двух словах свой опыт не обьяснить, а вы... когда нибудь поймете.

[Дмитрий Евграфович]

Юрий: После прочтения этой ветки появилось ощущение, что инженер-проектировщик, занимающийся разработкой чертежей небоскребов уже лет 15 встретил человека, у которого был некоторый опыт строительства замков из песка на пляже. И теперь второй исходя из своего опыта доказывает первому, что фундамент небоскребам не нужен и вообще строить все надо только на песке и из песка.

[Юрий]

Дмитрий Евграфович: да. наверное проблема в отсутствии хорошего образования. по хорошему "разработать свой фреймворк" это неплохая тема для курсовой работы в ВУЗе. Такая практическая работа дает хороший уровень понимания, как это делается и зачем. Но на производстве эти поделия из курсовой использовать нельзя, там свои инструменты более совершенные и проверенные временем.

Answer 2

[Александр Аксентьев]

$obj = new StdClass();
  $obj->fn = new StdClass();
  $obj->fn->move = function ($a, $b) {
    print_r($this);
    return $a * $b;
  };
  
  var_dump($obj->fn->move);
  
  $move = $obj->fn->move;
  
  $move(1,2);

move не метод класса, а переменная, поэтому фатал.

stackoverflow.com/questions/9355377/declaring-an-a...
stackoverflow.com/questions/4535330/calling-closur...

Comments

[Григорий Васильков]

Точно. Блин ну это ж косяк, постоянно присваивать в переменную жесткач. Точно такой подход не катит. Значит php7 спасет мир