Александр Х: по поводу функций насколько я помню он не анализирует параметры функции, а просто вызовет ее со всеми указанными аргументами, так что на 99% это должно сработать.
Григорий Васильков: именно это и значит мой фраза "когда нибудь поймете". это не понты и не к тому что вы обязаны все сейчас взять и бросить и начать с фрейма с нуля. а к тому что реально надо время, чтобы все это прочувствовать, в двух словах свой опыт не обьяснить, а вы... когда нибудь поймете.
Mikhaliich: безопасная сделка через вебмани. но код подтвреждения нужно отдавать кому то третьему. этим вроде бы многие промышляют, но процентов 10 возьмут за такие услуги.
вопрос еще в том для каких целей это делается и в каких масштабах. если это разовая сделка купить чтото для себя то это вариант. если вы нефть продаете - то не вариант конечно.
Григорий Васильков: я вам искренне желаю удачи. я не считаю вас противником который где то там от меня по ту сторону баррикад.
просто сейчас в вас я себя узнал лет 5 назад. если вспомнить также думал и говорил. То что я сейчас писал, это отчасти я писал как бы себе в прошлом. хотя конечно и понимаю что бесполезно было бы ;)
поэтому когда я пишу "удачи вам" это не подколка, типа "давай давай, посмотрим потом кто последний смеяться будет". мое мнение сформированно моим опытом и да, признаю, мой опыт может быть ошибочен и привел меня не к тому куда мог бы, но сейчас (по крайней мере пока) я чувствую себя хорошо.
и по второму пункту, вы преполагаете что мне тогда просто не повезло, а вам повезет.
все дело исключительно в том что качество удобство и функциональность фреймворка все таки очень сильно зависит от размера коммюнити которое его развивает. силами нескольких человек сложно сделать то же что и сделано силами тысяч людей. дело не в удаче, сила в размере людей которые поддерживают систему. у вас есть шанс только если привлечете коммюнити. но коммюнити любит когда уже все готовое и это замкнутый круг.
понятно что и своими силами можно многое сделать, но в какой то момент начнете задыхаться, нужно делать слишком много того что уже не раз сделано у других. но вас может спасти то, что проекты будут плюс минус однотипные, то есть новых функций каждый раз будет не так много, тогда вас хватит значительно надольше.
и еще нюанс, даже я умея полноценно работать на фрейморвках иногда отказываюсь от них или пилю чтото свое небольшое, типа свой минифреймворк.
вот например ссылочка https://toster.ru/answer?answer_id=950627 тут я наоборот агетирую за то что фреймворки это не всегда хорошо. и что есть случаи когда надо писать свой фреймворк. но я убежден что новые фреймворки можно уже писать когда основтаельно порабоатл с чужими и осознал их плюсы и минусы. а когда плюхаешься в ООП, то перспективы туманны.
тем не менее удачи вам желаю. честно и искренне. по крайней мере написание фреймворка это хороший способ изучить язык, мне это многое дало, хотя и дорого стоило.
Александр Х: нет, для таких целей тернарный оператор только.
вот описанием всех фич синтакиса symfony.com/doc/current/components/expression_lang...
любое выражение в нем это реально одно выражение которое чтото должно вернуть, без промежуточных переменных.
Григорий Васильков: вопрос в том что в вашем случае идиоту нужно показывать и обьяснять. возьмите любой фрейм - если объяснить, то там тем более любой поймет.
к тому же там и обьяснять не надо - есть доки.
вообще я с самого начала конечно понимал что вас не переубежду. сам когда то свои фреймворки делал. тоже считая что делаю что-то очень простое и понятное. сейчас понимаю что это был всего лишь страх. страх что несправлюсь с фреймом, а на своем я всегда знаю где что. знаю что сейчас вы на своем останетесь, а через N лет поймете о чем я говорил.
Григорий Васильков: итого более высокие зп тех кто пишет на фреймворках это ни разу не маркетинг, а повышение шансов того что
1) проект будет доделан (то есть вы не сольетесь когда поймете что дохрена всего наделали а новые требования не укладываются в вашу концепцию, а переделывать слишком долго)
2) сделан быстро (без лишней работы)
3) стандартизированно (понятно другим программистам)
Григорий Васильков: если вы пишите мелкий одноразовый проект, типа сделал и забыл - то все ок, но если какой то боле менее средний проект, то своего работодателя вы подставляете дважды. во первых беря деньги за написание ненужного ему фреймворка, во вторых привязываете себя к этому проекту до его конца.
и вот это как раз хитрый ход, садите его на абонентскую плату, сменить разработчика для него будет нереальными тратами, с учетом того что мало кто возьмется за такое, в итоге или платить каким то неадекватным чувакам любые деньги за поддержку либо переписать все с нуля, вытянуть новый лотерейный билетик.
"модные" фреймворки появляются не от того чтобы зарабатывать больше, а от того что более менее средний проект (и уж тем более крупный) если делать без, них превращается в кашу.
плюс вы пишите что больше зарплата. но ведь вы сейчас занимаетесь написанием своего какого то фреймворка, вместо того чтобы решать бизнес задачи. то есть вы впустую тратите деньги вашего работодателя на свое обучение и развлечение. я получаю больше, но я не делаю лишней работы, мне не нужно писать лишний код, фреймворк. все это сделано кем то когда то и я могу не отвлекаясь на эти мелочи заняться задачами бизнеса.
ваше рассуждение про менеджеров основывается на мелких студиях где менеджеры вчера продавали машинное масло, сегодня продают сайты. в крупных компаниях менеджеры это профессионалы, многие из них выросли из программистов. и их простым маркетинговым булшитом (которым ввы все обьясняете) не обманешь.
проект на фреймворке это
- быстрая скорость разработки (при условии что вы знаете его)
- более простая поддержка
- возможность безболезненно передать проект другому программисту.
вы сейчас пишите свой фреймворк или какой то базовый код, незнаю что там у вас. а представьте вы заболеете, умрете, или просто уйдете, то кто будет поддерживать ваш код? если там будет код как вы написали выше - то только ненормальные. поэтому фреймворк это и более качественный код, протестированный, документированный.
Григорий Васильков: "Как таковые неймспейсы решают проблемы избыточных имен, источником которой является избыточное количество классов там где на самом деле нужны просто обьекты, обученные методам."
вас же никто не завтсавляет пользоваться ООП подходом, пхп испокон веков работает и процедурный стиль. если вы не понимаете ООП, то зачем себя так мучать. ООП могут использовать только те кому они реально нужны.
вы делаете из себя жертву какую то, но никто вас не заставляет ей быть ;)
пишите процедурно, можно даже как в ноде все сделать впринципе.
ваша попытка использовать StdClass это и есть впринципе процедурный подход, просто вы зря классы выбрали, я уже писал что в пхп обычные массивы это аналоги js обьектов - используйте их и не парьтесь.
Григорий Васильков: по поводу симфони все просто на самом деле.
если возьмем ноду то такая же простыня будет из require, только require нужно писать руками да еще названия придумывать, а use заполняет IDE, о них вообще забываешь, современный код не пишется в блокноте.
все эти вещи знать не нужно, так же как и везде надо только знать как их использовать, достаточно доков, так же как и в js.
конечно у симфони высокий порог входа, сам когда то боялся, но когда умеешь ей пользоватьося, сложные задачи решаются быстро и легко.
начиная пилить свой фреймворк с одной стороны вроде можешь получит ькакой то результат сразу же, но со временем начинаешь отставать, постоянно рефакторишь все, велосипедишь и понимаешь что гибкости не хватает.
Григорий Васильков: "мне задалбывает их переименовывать постоянно при переносе из одной папки в другую по мере проектирования"
PHPStorm рефакторинг делает сам (shift + F6).
Григорий Васильков: все таки не могу понять вашей проблемы. с класами все просто и логично, просто вам надо почитать/посомтреть что-то и понять как они работают.
то что вы контролллеры синглтонами делаете - это явно уже попахивает.
что вы хотите синглтонами там добится? синглтоны удобны тем чтобы иметь во время выполнения ровно один экземпляр класса, (то есть случайно не создать два) и иметь к нему быстрый доступ из любого места кода.
вообще говоря когда то была мода но них, изза простоты, но синглтоны вообще стоит избегать, потому что если будете писать тесты то еще отхлебнете с ними.
myswitch( [bool1, value1, bool2, value2, ...] )
то есть все аргументы - одним аргументом массивом