Идеология SKY подразумевает в codebase разный код. База кода — это некоторое подобие композер и пакажист. Вы можете туда загрузить этот код.
Я только что установил PHP 7 — все нормально работает. Вроде бы в «right way» у вас short_open_tag должен быть Off — включите его, возможно в этом дело.
Идеология SKY подразумевает коллективную работу над одними и теми же файлами. Кто угодно, может улучшить в том числе наиболее часто употребимый файл — main/sky.php. У вас же:
структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
такая идеология скоро создаст на пакажист помойку и будет трудно найти хороший пакет так как будет представлено много альтернативных. Имя вендора не имеет ничего общего по отношению к функционалу который он предоставляет, поэтому не должно быть включенно в названии.
Если бы вы «изучили инструмент», то поняли бы, что работа с двумя БД одновременно не является частым случаем (точно менее 30% покрытия) и поэтому в clear-cloud файл не включена. Мое видение, если вам нужно работать с postgresql — просто меняете файл main/sky.php который является портом файла для mysql (clear-cloud). Если работаете с 2 БД одновременно (как раз я работал на Zend так, и считаю их решение уродливым), то вы подгружаете файл третьего крыла (редко употребимый код) и автозагрузчик его использует.
При работе с 2 БД, как правило 1 БД основная и с ней удобнее работать так же как и в приложениях с 1 БД.
ваш «тривиально простой код» не работает в 7й версии, а активная поддержка 5.6 закончится в конце этого года, что делает ваш код не особо пригодным к продакшну. И не думаю, что ваш код будет очень быстрым, сравните производительность с phalcon.
Это просто моя (согласен важная) недорабока, которая будет исправлена. Мы сейчас говорим, о фундаментальных вещах, об общем подходе, стратегии и архитектуре. С вашей стороны глупо, простите, приводить как аргументы то что вы написали. SKY Framework также несложно упаковать как расширение для PHP, переписать на С/C++ и только тогда уж нужно меряться по производительности с phalcon.
Я у вас спросил «А зачем ORM вообще?» Первое, что вы мне сказали — короче запись, делаем $user = new User и так мы добавляем нового пользователя. А запись: sql(«insert into users () values ()») намного длинее? Но вы забыли, что вам еще нужно отконфигурировать ORM, так что ничем не короче. Плюс, вы юзаете код ORM который может содержать доп. источник ошибок, изучаете его документацию, понижаете быстродействие.
«right way» и трендовые фреймворк, имхо, это просто игра запутавшихся программистов, которые играют в некотором нереальном поле. На фоне получения удовольствия творчества и довольствования своими способностями, вы не сильно обращаете внимание на реальность. Несмотря на высокий IQ у гуру «right way», вы не можете сбросить шелуху из мыслей и посмотреть на то что происходит чистым взлядом. Имею ввиду то, что я бы назвал «open your mind» (фильм «Вспомнить все»)
Вещи нужно создавать, когда в них есть потребность. По этой причине, я считаю бессмыслено иметь ORM, как дефолтный способ работы с БД, в ваших роутерах просто нет необходимости. Компилируемые шаблонизаторы просто не нужны, потому что шаблоны PHP сами по себе идеально могут справляться с поставленной задачей. Идея twig интересна, но не нужна. И так далее, список могу продолжить.
Из трендовых фреймворк, я отдал бы предпочтение Yii по причине PHP шаблонов и другим вещам. Но критика в его сторону: в примерах которые он приводит, много ненужного кода в файлах представлений. Этого можно и нужно не делать.
MetaDone, я не то что верю, я знаю, что сайты на SKY Framework могут масштабироваться до очень сложных и много функциональных приложений. Результат при этом будет достигаться быстрее и качественнее чем, например, на симфони.
Имхо разумный уровень гибкости покрытие 70% сайтов в интернете. Какой разумный по-вашему уровень гибкости? Параноидально гибкий (максимально) это хорошо? Читайте о clear cloud и cloud modification на сайте
http://ru.coresky.net/roots?id26
http://ru.coresky.net/roots?id33
В моем понимании «full stack framework» — это значит, нужно мне например везде array() заменить на [] и пару раз кликнул в приложении DEV и сделал это. Существует несколько десятков таких типов задач, которые должен легко решать «full stack framework». DEV должен быть всегда под рукой. Не нужно лезть в БД композера искать классы и мастерить скрипт для такой замены на [], это долго. Может этот пример не слишком убедительный в плане необходимости DEV, но работа с таблицей _lang более убедительна (ищите на моем сайте), а также смотрите иной функционал
«right way» имхо, выдвинуло некоторые теоретические догмы и им следуют упуская важное. Так и понятие «full stack framework» в некоторой абстрактной теоретической плоскости. А зачем нам теория? Должны быть практические догмы. На симфони вообще невозможно построить приложение DEV такого же компактного уровня. Как на симфони построить компактное приложение?
На сайте симфони написано — будет PHPBB использовать симфони, но только прошло 3 года а новой версии PHPBB на симфони нет. (я где то читал что собрались форум PHPBB переписать на симфони еще в 2013 году) Команда профессионалов переписывает форум уже 3 года. Браво симфони, работать видимо команде PHPBB легко и приятно, кто только у них придумал переезжать на симфони). Эти ребята всегда писали в глобальную область видимости и сейчас наверно «балдеют» ) Их работа от этого не была менее популярна.
Проблема не в том, что сложны решения, а в том что в сложности нет необходимости. Я работал с Zend.1 больше года, в очень крупной компании. Мои веб-приложения в продакшн прекрасно работают. Мой общий опыт в программировании более 20 лет, в PHP — 12 лет. Проблема в том, что мне хотелось постоянно материться, когда я работал с Zend из-за неверных, по моему мнению, решений в фреймворк. Из списка «ваших трендовых фреймворк» это все, но я считаю этого достаточно, чтобы говорить о том, что я имею о них представление.
Базовые принципы «right way» говорят: не создаем ничего в глобальной области видимости, не используем eval(), не применяем подавление ошибок @ (3 правила X), — так мы гарантированно избежим ошибок определенного вида! Я очень согласен с этим и поддерживаю. Но «right way», имхо, принебрежительно отнесся к тому что «на обратной стороне луны».
Я пришел к вам «подвинуть» «right way» (напрасно вы так воспринимаете -«лососнуть тунца»). Многие просто не понимают сколько мы теряем, приняв 3 правила X и что есть на обратной стороне луны. А там — тривиально простой код, намного более высокая производительность и еще много чего хорошего. Я просто чувствую и уверен что «right way» неверен, и у вас неверные весы. Вы отдали предпочтение тому, что менее важно. Тем не менее, я часто сталкиваюсь с программистами, которые с открытой душой приемлят «right way» и я не знаю, почему вы не видите то что и я. Благодаря геометрично увеличивающейся сложности, я считаю «right way» утопичен. И даже дело, не в трех правилах X, возможно в SKY что-то таки следует менять из трех правил X. Я пришел к вам показать новую работу и мое видение построения технологии для получения идеального кода (хотя сама статья была только о шаблоне CSN-Ajax). Вы увидели не следование мной 3 правилам Х и сразу же пустили работу в топку. Я могу делать допущения, когда изучаю новый предмет. Того же мне хотелось видеть в вас, обсуждать детали SKY Framework в спокойном тоне. Я не призываю никого, бросить симфони и начать работать в SKY, это может быть просто хобби, пока не появится «right way++». Какой бы у вас не был IQ вы не сможете смоделировать 5 летнюю работу с SKY Framework в уме, чтобы адекватно оценить работу и говорить о нем в таком тоне, в каком говорите. Хотелось бы мне увидеть ваш код, который вы (или кто там) писали в 10 классе, я уверен — ну не писали вы так… я бы взлянул и указал на 100 явных недостатков. Знал я одного вундеркинда, он первый находил к чему придраться, а когда я взглянул в его код — путаница…
Двигать авторитетов можно и нужно, иначе бы слово «прогресс» было бы пустым звуком и новые знания не рождались бы в муках. Джордано Бруно сказал всем что земля круглая и его сожгли, так как пришел без доказательств. Энштейн подвинул Ньютона, но пришел с доказательствами — его сделали дилехтором ). Я уверен на 100% последнего можно и нужно также двигать и любого авторитета в науке. Я даже верю в путь: а) нет никакой темной энергии и материи; б) все дело в
http://ru.coresky.net/blog?id43 — дотошно вникните в суть статьи, если вы молодой физик. Теорию меняем, формулы новые, объясняем движение звезд в галактиках, расширяющуюся вселенную и еще пару подтверждений в опытах. Извиняюсь за оффтоп, — не удержался чтобы не написать.
В «right way» точного доказательства нет и быть не может, как и в SKY way… Спор может разрешить только опыт и конструктивная дискуссия профессионалов.
Предостережение для молодых программистов: если вы хотите крепко стать на ноги — работайте только с «right way», спрос на рынке труда именно таков. Но если вы крепко стоите на ногах — приглашаю вас на мой проект. Изучать, пробовать, экспериментировать, творить вместе. Сначала как хобби.
«right way» принебрежительно относится к увеличивающейся сложности фреймворк, постоянно выбирает сложное решение, даже там где подошло бы простое. Мое субъективное мнение такое: большинство программистов получает удовольствие от своего кода: «вот как я круто написал, красота то какая, кругом одни классы и в том же духе»… А ничего крутого в куче классов нет, все гениальное просто. Я не знаю как объяснить вам, что между кодом который выглядит на вид одинаково просто (так же как и вы писали в 10 классе) может быть огромная пропасть. Ну пусть даже не в самом коде, а в подходе, в пути развития.
Я считаю в программировании было 2 прорыва: первый язык С, второй — языки высокого уровня. Кто там первый полноценно сформировавшийся? Perl, Java? Не важно. Я уверен точно — «right way» прорыв не грозит. Языки высокого уровня: убрали препроцессор, автопривидение типов, удобные типы данных и т.д. только упрощения (в сравнении с С/C++) с ориентацией на web. «right way» рубит сук на котором сидит — нещадно увеличивает сложность.
Меня поражает, то что вы не можете остудить голову читая что я пишу и одновременно продолжаете следить за топиком. Я бы на вашем месте давно выключил слежение и занялся более полезными делами.
— зачем?
Сейчас в современном php принята структура наименований классов — имя вендора/имя пакета/пространство имен пакета/название класса
Пример: Aura\SqlQuery\Mysql\Delete
Ваша идея — бессмысленна. Почитайте про psr-4 — что тут непрозрачного? Всегда понятно что и где находится.
Это элементарно понять что я писал в данном случае не о прозрачности, а о избыточности функционала NAMESPACE.
Все… постараюсь больше не писать сюда ни комментов не статей.
На этом мой бенефис на хабре окончен. Всем спасибо.
Когда мне здесь советуют предпочитать строгое сравнение === нестрогому == это значит рубить сук на котором сидишь. Для всех языков программирования разумна может быть только одна тенденция — к сокращению кода. Только так, в частности, область программирования, да и программирование в целом может получить новый значимый прорыв.
Появление языков высокого уровня как PHP, дало прорыв в краткости кода и скорости написания программ в сравнении например с C/C++ при реализации эквивалентного функционала. Привидение типов данных, массивы, хеши, все это супер при применении в веб. У PHP сейчас имеется тенденция к сокращению кода: вместо array() можно писать []. Анонимные функции, Closure. Я это поддерживаю. А у создателей фреймворк тенденция к увеличению кода: мне здесь сказали, что если я пишу function, то правильно писать public function в методе класса и еще много чего… Если отбросить то что вы категорически неприемлете (писание в глоб. область, применение eval, @) — посмотрите код сгенерированного сайта на видео (которое на главной странице проекта SKY) http://ru.coresky.net/download?video1.sky.zip он отличается как небо и земля от NULL сайт на симфони. И при определенных допущениях, по всем показателям лучше эквивалентного на симфони. Он прозрачен как на ладони, он быст и еще много чего. Там много кошерных классных решений.
Я почитаю Брайана Кернигана и Денниса Ритчи больше чем создателей PHP, хотя и их тоже. Надеюсь они не прочтут это и не будут обижены ). Создатели С это первый и самый большой «прорыв». В PHP массивы позволили писать как []. По этой же причине не нужно было вводить ключевое слово function. В языке низкого уровня С его нет, а в PHP (высокого) ввели… напрасно… Откройте любой файл на PHP и удалите слово function везде — он не станет менее читаем, в С же все ок. Вы представляете сколько трудо-часов в мировом масштабе тратятся на абсолютно бесполезные действия и одного из них набирать на клавиатуре слово function? По той же причине я бы еще много чего поменял в PHP, и фреймворках на PHP, но это отдельная тема… Трудно быть именитым…
Не буду писать отдельную статью, напишу комментарием, не хочу чтобы меня обзывали троллем. Так меня еще никто не обзывал)
Сомнительная необходимость NAMESPACE
NAMESPACE это продолжение все той же истории, что и переменные в глобальной области видимости. Чтобы имена не пересеклись ввели NAMESPACE. Этого не надо было делать. Мое кошерное решение: композер на входе должен иметь PHP парсер кода и БД уникальных имен классов и интерфейсов, дирректорий внутри папки vendor. Фреймворк должен иметь приложение DEV, как есть в DEV.SKY. Есть зачаток такого приложения в Yii с генерацией файлов CRUD, в симфони только консольная утилита (этого мало). В приложении есть кнопка где можно сделать тоже самое — собрать уник. имена классов, чтобы они не пересеклись. Парсер PHP должен быть частью PHP, хороших реально-практически нужных задач для него много. Задача пересечения имен была бы решена на 100% более простым способом. Если вы скажете, что NAMESPACE дает много больше имен и в БД композера началась бы неразбериха, как подобная может быть при регистрации нового ник-нейма на популярном ресурсе, то я вам отвечу: вот именно это я называю помойкой. Я считаю, что должно быть так: один автор сделал класс и положил на композер. Другому класс понадобился он его скачал, но увидел что он плох. Модифицировал его, использовал в своем проекте, свое гениальное дополнение прокомментировал и положил на композер новую версию, добавился там автором.
Посмотрите что произошло с введением NAMESPACE: в институтах ввели новую лабораторную работу по NAMESPACE. Автор симфони и миллионы других занялись портированием своей работы в синтаксис с NAMESPACE. Это пустая трата времени. Код PHP стал менее прозрачный и медленее работать.
Надеюсь мое кошерное решение с NAMESPACE более значимо и прозрачно чем то что я пишу в глобальную область? Уберите огонь из души и настройтесь на чистый разум, может быть вы поймете, что мое решение хорошее? Я признаю, я был не готов отвечать по поводу моего писания в глобальную область. Я бы не хотел быть тем дядей Васей, который сказал писать туда можно, все меня послушали, а потом меня кто-то обвинил, что потерял очень много благодаря мне. А вы можете адекватно и честно оценить эту мою мысль?
На самом деле пропасть между именитыми умами и умом десятиклассника не так велика как кажется. Я приведу пример: разработчики PHP придумали magic quotes… Я думаю, что если я бы был в их команде, я бы сразу легко указал что это бред. Я их не обличаю, искренне думаю, наверно они это спьяну сотворили. Сейчас magic quotes отмирает, что вполне логично.
Другой пример: когда-то они будучи навеяны (были времена) трендом витающим в облаках который именуется «self described identifier» придумали $HTTP_GET_VARS, потом переименовали в $_GET и это хорошо. Это пример как витающие тренды вредят и нужно все воспринимать окружающих холодным рассудком.
Еще хочу сказать почему так: когда ко мне приходит хорошая идея я получаю удовольствие, когда я раньше работал с Zend я злился. Я хочу, чтобы работа не была в напряг, хочу получать удовольствие творчества.
Верно поняли. Я имел ввиду, что мою работу нужно корректировать. Знал и о композере и PHP FIG и глоб. области и о eval и что получу подобную реакцию здесь. Но не знал, что она повлияет на меня так. Это не значит, что я буду работать с симфони или подобным фреймворком. Ну не приемлет у меня душа этот современный подход… Буду искать альтернативные решения наверно, например, в сторону анализаторов кода, чтобы результат был не хуже чем: не пишем в глобальную область — значит 100% не получим ошибки такого типа, анализировать теорию и практику, между ними бывает пропасть.
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
Волевым решением сообщество решило не писать в глобальную область видимости. Но это одно из тех решений когда оно есть палка о двух концах. Решив одну проблему, оказалось что нужно писать больше кода и он стал сложнее для восприятия, думаю что также код стал более медленный (3 минуса)
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Конечно, мне ваше мнение интересно. Иначе зачем бы я делал сайт в том виде в каком он есть? Это проект для программистов.
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
52, 61 — это просто вручную посчитано кол-во элементов массива, он не меняется.
7 — пароль нормального уровня сложности, энтропии. Если хотите считайте начальный пароль, позже пользователь переопределит его.
23 — куки нормальной энтропии, чтобы не быть подобранной, но чтобы и не быть очень длинной
Эти цифры сейчас проставлены мной интуитивно. Идеально математически просчитать кол-во вариантов и выбрать.
Я только что установил PHP 7 — все нормально работает. Вроде бы в «right way» у вас short_open_tag должен быть Off — включите его, возможно в этом дело.
Вы просто троллите меня? )
такая идеология скоро создаст на пакажист помойку и будет трудно найти хороший пакет так как будет представлено много альтернативных. Имя вендора не имеет ничего общего по отношению к функционалу который он предоставляет, поэтому не должно быть включенно в названии.
Если бы вы «изучили инструмент», то поняли бы, что работа с двумя БД одновременно не является частым случаем (точно менее 30% покрытия) и поэтому в clear-cloud файл не включена. Мое видение, если вам нужно работать с postgresql — просто меняете файл main/sky.php который является портом файла для mysql (clear-cloud). Если работаете с 2 БД одновременно (как раз я работал на Zend так, и считаю их решение уродливым), то вы подгружаете файл третьего крыла (редко употребимый код) и автозагрузчик его использует.
При работе с 2 БД, как правило 1 БД основная и с ней удобнее работать так же как и в приложениях с 1 БД.
Это просто моя (согласен важная) недорабока, которая будет исправлена. Мы сейчас говорим, о фундаментальных вещах, об общем подходе, стратегии и архитектуре. С вашей стороны глупо, простите, приводить как аргументы то что вы написали. SKY Framework также несложно упаковать как расширение для PHP, переписать на С/C++ и только тогда уж нужно меряться по производительности с phalcon.
«right way» и трендовые фреймворк, имхо, это просто игра запутавшихся программистов, которые играют в некотором нереальном поле. На фоне получения удовольствия творчества и довольствования своими способностями, вы не сильно обращаете внимание на реальность. Несмотря на высокий IQ у гуру «right way», вы не можете сбросить шелуху из мыслей и посмотреть на то что происходит чистым взлядом. Имею ввиду то, что я бы назвал «open your mind» (фильм «Вспомнить все»)
Вещи нужно создавать, когда в них есть потребность. По этой причине, я считаю бессмыслено иметь ORM, как дефолтный способ работы с БД, в ваших роутерах просто нет необходимости. Компилируемые шаблонизаторы просто не нужны, потому что шаблоны PHP сами по себе идеально могут справляться с поставленной задачей. Идея twig интересна, но не нужна. И так далее, список могу продолжить.
Из трендовых фреймворк, я отдал бы предпочтение Yii по причине PHP шаблонов и другим вещам. Но критика в его сторону: в примерах которые он приводит, много ненужного кода в файлах представлений. Этого можно и нужно не делать.
MetaDone, я не то что верю, я знаю, что сайты на SKY Framework могут масштабироваться до очень сложных и много функциональных приложений. Результат при этом будет достигаться быстрее и качественнее чем, например, на симфони.
http://ru.coresky.net/roots?id26
http://ru.coresky.net/roots?id33
«right way» имхо, выдвинуло некоторые теоретические догмы и им следуют упуская важное. Так и понятие «full stack framework» в некоторой абстрактной теоретической плоскости. А зачем нам теория? Должны быть практические догмы. На симфони вообще невозможно построить приложение DEV такого же компактного уровня. Как на симфони построить компактное приложение?
На сайте симфони написано — будет PHPBB использовать симфони, но только прошло 3 года а новой версии PHPBB на симфони нет. (я где то читал что собрались форум PHPBB переписать на симфони еще в 2013 году) Команда профессионалов переписывает форум уже 3 года. Браво симфони, работать видимо команде PHPBB легко и приятно, кто только у них придумал переезжать на симфони). Эти ребята всегда писали в глобальную область видимости и сейчас наверно «балдеют» ) Их работа от этого не была менее популярна.
Базовые принципы «right way» говорят: не создаем ничего в глобальной области видимости, не используем eval(), не применяем подавление ошибок @ (3 правила X), — так мы гарантированно избежим ошибок определенного вида! Я очень согласен с этим и поддерживаю. Но «right way», имхо, принебрежительно отнесся к тому что «на обратной стороне луны».
Я пришел к вам «подвинуть» «right way» (напрасно вы так воспринимаете -«лососнуть тунца»). Многие просто не понимают сколько мы теряем, приняв 3 правила X и что есть на обратной стороне луны. А там — тривиально простой код, намного более высокая производительность и еще много чего хорошего. Я просто чувствую и уверен что «right way» неверен, и у вас неверные весы. Вы отдали предпочтение тому, что менее важно. Тем не менее, я часто сталкиваюсь с программистами, которые с открытой душой приемлят «right way» и я не знаю, почему вы не видите то что и я. Благодаря геометрично увеличивающейся сложности, я считаю «right way» утопичен. И даже дело, не в трех правилах X, возможно в SKY что-то таки следует менять из трех правил X. Я пришел к вам показать новую работу и мое видение построения технологии для получения идеального кода (хотя сама статья была только о шаблоне CSN-Ajax). Вы увидели не следование мной 3 правилам Х и сразу же пустили работу в топку. Я могу делать допущения, когда изучаю новый предмет. Того же мне хотелось видеть в вас, обсуждать детали SKY Framework в спокойном тоне. Я не призываю никого, бросить симфони и начать работать в SKY, это может быть просто хобби, пока не появится «right way++». Какой бы у вас не был IQ вы не сможете смоделировать 5 летнюю работу с SKY Framework в уме, чтобы адекватно оценить работу и говорить о нем в таком тоне, в каком говорите. Хотелось бы мне увидеть ваш код, который вы (или кто там) писали в 10 классе, я уверен — ну не писали вы так… я бы взлянул и указал на 100 явных недостатков. Знал я одного вундеркинда, он первый находил к чему придраться, а когда я взглянул в его код — путаница…
Двигать авторитетов можно и нужно, иначе бы слово «прогресс» было бы пустым звуком и новые знания не рождались бы в муках. Джордано Бруно сказал всем что земля круглая и его сожгли, так как пришел без доказательств. Энштейн подвинул Ньютона, но пришел с доказательствами — его сделали дилехтором ). Я уверен на 100% последнего можно и нужно также двигать и любого авторитета в науке. Я даже верю в путь: а) нет никакой темной энергии и материи; б) все дело в
http://ru.coresky.net/blog?id43 — дотошно вникните в суть статьи, если вы молодой физик. Теорию меняем, формулы новые, объясняем движение звезд в галактиках, расширяющуюся вселенную и еще пару подтверждений в опытах. Извиняюсь за оффтоп, — не удержался чтобы не написать.
В «right way» точного доказательства нет и быть не может, как и в SKY way… Спор может разрешить только опыт и конструктивная дискуссия профессионалов.
Предостережение для молодых программистов: если вы хотите крепко стать на ноги — работайте только с «right way», спрос на рынке труда именно таков. Но если вы крепко стоите на ногах — приглашаю вас на мой проект. Изучать, пробовать, экспериментировать, творить вместе. Сначала как хобби.
«right way» принебрежительно относится к увеличивающейся сложности фреймворк, постоянно выбирает сложное решение, даже там где подошло бы простое. Мое субъективное мнение такое: большинство программистов получает удовольствие от своего кода: «вот как я круто написал, красота то какая, кругом одни классы и в том же духе»… А ничего крутого в куче классов нет, все гениальное просто. Я не знаю как объяснить вам, что между кодом который выглядит на вид одинаково просто (так же как и вы писали в 10 классе) может быть огромная пропасть. Ну пусть даже не в самом коде, а в подходе, в пути развития.
Я считаю в программировании было 2 прорыва: первый язык С, второй — языки высокого уровня. Кто там первый полноценно сформировавшийся? Perl, Java? Не важно. Я уверен точно — «right way» прорыв не грозит. Языки высокого уровня: убрали препроцессор, автопривидение типов, удобные типы данных и т.д. только упрощения (в сравнении с С/C++) с ориентацией на web. «right way» рубит сук на котором сидит — нещадно увеличивает сложность.
Это элементарно понять что я писал в данном случае не о прозрачности, а о избыточности функционала NAMESPACE.
Все… постараюсь больше не писать сюда ни комментов не статей.
На этом мой бенефис на хабре окончен. Всем спасибо.
Я почитаю Брайана Кернигана и Денниса Ритчи больше чем создателей PHP, хотя и их тоже. Надеюсь они не прочтут это и не будут обижены ). Создатели С это первый и самый большой «прорыв». В PHP массивы позволили писать как []. По этой же причине не нужно было вводить ключевое слово function. В языке низкого уровня С его нет, а в PHP (высокого) ввели… напрасно… Откройте любой файл на PHP и удалите слово function везде — он не станет менее читаем, в С же все ок. Вы представляете сколько трудо-часов в мировом масштабе тратятся на абсолютно бесполезные действия и одного из них набирать на клавиатуре слово function? По той же причине я бы еще много чего поменял в PHP, и фреймворках на PHP, но это отдельная тема… Трудно быть именитым…
Сомнительная необходимость NAMESPACE
NAMESPACE это продолжение все той же истории, что и переменные в глобальной области видимости. Чтобы имена не пересеклись ввели NAMESPACE. Этого не надо было делать. Мое кошерное решение: композер на входе должен иметь PHP парсер кода и БД уникальных имен классов и интерфейсов, дирректорий внутри папки vendor. Фреймворк должен иметь приложение DEV, как есть в DEV.SKY. Есть зачаток такого приложения в Yii с генерацией файлов CRUD, в симфони только консольная утилита (этого мало). В приложении есть кнопка где можно сделать тоже самое — собрать уник. имена классов, чтобы они не пересеклись. Парсер PHP должен быть частью PHP, хороших реально-практически нужных задач для него много. Задача пересечения имен была бы решена на 100% более простым способом. Если вы скажете, что NAMESPACE дает много больше имен и в БД композера началась бы неразбериха, как подобная может быть при регистрации нового ник-нейма на популярном ресурсе, то я вам отвечу: вот именно это я называю помойкой. Я считаю, что должно быть так: один автор сделал класс и положил на композер. Другому класс понадобился он его скачал, но увидел что он плох. Модифицировал его, использовал в своем проекте, свое гениальное дополнение прокомментировал и положил на композер новую версию, добавился там автором.
Посмотрите что произошло с введением NAMESPACE: в институтах ввели новую лабораторную работу по NAMESPACE. Автор симфони и миллионы других занялись портированием своей работы в синтаксис с NAMESPACE. Это пустая трата времени. Код PHP стал менее прозрачный и медленее работать.
Надеюсь мое кошерное решение с NAMESPACE более значимо и прозрачно чем то что я пишу в глобальную область? Уберите огонь из души и настройтесь на чистый разум, может быть вы поймете, что мое решение хорошее? Я признаю, я был не готов отвечать по поводу моего писания в глобальную область. Я бы не хотел быть тем дядей Васей, который сказал писать туда можно, все меня послушали, а потом меня кто-то обвинил, что потерял очень много благодаря мне. А вы можете адекватно и честно оценить эту мою мысль?
На самом деле пропасть между именитыми умами и умом десятиклассника не так велика как кажется. Я приведу пример: разработчики PHP придумали magic quotes… Я думаю, что если я бы был в их команде, я бы сразу легко указал что это бред. Я их не обличаю, искренне думаю, наверно они это спьяну сотворили. Сейчас magic quotes отмирает, что вполне логично.
Другой пример: когда-то они будучи навеяны (были времена) трендом витающим в облаках который именуется «self described identifier» придумали $HTTP_GET_VARS, потом переименовали в $_GET и это хорошо. Это пример как витающие тренды вредят и нужно все воспринимать окружающих холодным рассудком.
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
52, 61 — это просто вручную посчитано кол-во элементов массива, он не меняется.
7 — пароль нормального уровня сложности, энтропии. Если хотите считайте начальный пароль, позже пользователь переопределит его.
23 — куки нормальной энтропии, чтобы не быть подобранной, но чтобы и не быть очень длинной
Эти цифры сейчас проставлены мной интуитивно. Идеально математически просчитать кол-во вариантов и выбрать.