Все мы это кто, говнокодеры? В init.php максимум, что нужно дак это вызывать 'Loader::includeModule', а все остальное уже размещать непосредственно в include.php модуля и/или доп файлах если include.php разрастается.
Да-да, именно вынесения всей каши из init.php в отдельный файл и инклудить его обратно в init - это тру ?
Пожалуйста, не учите людей хорошим практикам, не владея ими самим ?
Symfony/EventDispatcher - фреймворк ? или может Twig - фреймворк ?
Все разрабатывается на одной платформе, в зависимости от задач используются те, или иные Библиотеки. Если какие-то Библиотеки были зарождены в рамках другого фреймворка, это не значит, что это не предполагает использования в другом контексте.
Для полного счастья остаются дженерики и get/set из шарпа. И желательно выкинуть текущий union-типы и сделать их в виде отдельной сущности, например как в С++.
Если рассматривать [RFC] User Defined Operator Overloads то можно сразу и рассмотреть перегрузку методов и функций, чтобы не допускать таких извращений: publicfunction __add(int|float|string|BigNumber $other, bool $left): self а в теле кучу if-else.
Не, согласен с расчетами и рассуждениями, т.к. вы по умолчанию считаете, что вакцина - даёт положительный результат в 99.9%.
Процент полезности (вреда) вакцины - это неизвестное, и его исходить из этого.
Из ваших примеров, про процент безопасности от спасательного жилета, каски и прочего - для обычного человека это прозрачные сущности, где он способен самостоятельно для себя понять преимущества
если люди потратили время и сделали функционал, это же не значит, что функционал должен радовать всех ?
PS.: я не один ждал этого функционала, и те, кто ждал, сталкивались со сложностями, которые легко решались бы через enumerations.
и enum — нужен только для группировки набора значений и возможность принимать один из объявленных значений.
enum COLOR {
RED = 1,
GREEN,
BLUE
}
function f(COLOR $color) { echo $color; }
f(COLOR::GREEN); // print 2
f(10); // fatal error
это весь функционал, который семантически предполагает enum.
все остальное — бесполезная мишура, которая усложняет код.
По поводу enum: я ждал этого функционала уже более 5 лет, но в результате получаем не то, что ожидали.
Для чего вся эта мишура с трейтами и т. д?
Почему не сделать как в c++?
А про распаковку массива с ключами как именованные аргументы это уже совсем…
Кому это надо? Это потенциальное место, где будут копиться баги.
И всем разработчикам, которые хотят распаковать массив в аргументы функции, надо заботиться, чтобы ключи были не именованные, а если забыл, то могут быть случайные совпадения ключей и наименований аргументов.
Дополнительно, при рефакторинге функции/метода, надо помнить о возможных входных данных и все это учитывать.
На мой взгляд php начал развиваться в не том направлении.
Слишком много уделяется внимание всяким бесполезным штучкам.
Взять нормальный функционал у одного языка, и сделать из него елку.
Можете пожалуйста чуть подробнее про сложности с властями?
У Битрикса в курсах тонны кода и рекомендаций с запашком, и не нужно всё впитывать из этих источников.
Вы используете композер, зачем вручную писать автозагрузку?
Когда будут подарки?)
Потому что js - это не язык программирования,
а джаваскриптизиоры - не программисты.
Мне кажется, или первое, что надо было сделать - это заняться изучением проблемы.
Начиная с sql запроса и индексов и заканчивая структурой базы?
15 сек для 100к записей - здесь явно что-то не так.. Конечно, если у вас у железа не 256мб ОЗУ.
Если не ошибаюсь, именно на этот проект было субсидирование 2,1 млрд рублей.
Поэтому говорить, что это стартап, у которых не было денег на дизайнера и на верстальщика - звучит странно.
в этом случае, отсутствие доступа github/gitlab будет не самой приоритетной проблемой для разработчиков.
Не знаю, какой у них там функционал планируется, но я открыл сайт gitflic.ru - как будто верстал студент первокурсник в качество лабораторной работы.
Это лицо портала, и оно точно не должно быть таким.
Также, самый первый пункт в меню у них "Цены".
Какие еще цены? зачем, платить, если даже github сделал закрытие репы бесплатными ?
Первым пунктом должны быть Преимущества, которых, увы пока нет.
Да-да, именно вынесения всей каши из init.php в отдельный файл и инклудить его обратно в init - это тру ?
Пожалуйста, не учите людей хорошим практикам, не владея ими самим ?
Где вы заметили яйцо в яйце?
Symfony/EventDispatcher - фреймворк ?
или может Twig - фреймворк ?
Все разрабатывается на одной платформе, в зависимости от задач используются те, или иные Библиотеки. Если какие-то Библиотеки были зарождены в рамках другого фреймворка, это не значит, что это не предполагает использования в другом контексте.
Для полного счастья остаются дженерики и get/set из шарпа.
И желательно выкинуть текущий union-типы и сделать их в виде отдельной сущности, например как в С++.
Если рассматривать [RFC] User Defined Operator Overloads
то можно сразу и рассмотреть перегрузку методов и функций, чтобы не допускать таких извращений:
public function __add(int|float|string|BigNumber $other, bool $left): self
а в теле кучу if-else.
Не, согласен с расчетами и рассуждениями, т.к. вы по умолчанию считаете, что вакцина - даёт положительный результат в 99.9%.
Процент полезности (вреда) вакцины - это неизвестное, и его исходить из этого.
Из ваших примеров, про процент безопасности от спасательного жилета, каски и прочего - для обычного человека это прозрачные сущности, где он способен самостоятельно для себя понять преимущества
Тогда нужно использовать phpQuery, или другие готовые решения :)
Про слабые места php так и не услышал.
Думаю, нужно заменить заголовок статьи на "Общие вопросы специалисту по кибербезопасности"
Кроме рекламы, ни строчки полезной информации не заметил.
Искренне не понимаю, зачем нужен этот бестолковый фреймворк, напичканный антипаттернами со всех сторон.
Страшно представить, что будет с долгожданными дженериками.
если люди потратили время и сделали функционал, это же не значит, что функционал должен радовать всех ?
PS.: я не один ждал этого функционала, и те, кто ждал, сталкивались со сложностями, которые легко решались бы через enumerations.
и enum — нужен только для группировки набора значений и возможность принимать один из объявленных значений.
это весь функционал, который семантически предполагает enum.
все остальное — бесполезная мишура, которая усложняет код.
Для чего вся эта мишура с трейтами и т. д?
Почему не сделать как в c++?
А про распаковку массива с ключами как именованные аргументы это уже совсем…
Кому это надо? Это потенциальное место, где будут копиться баги.
И всем разработчикам, которые хотят распаковать массив в аргументы функции, надо заботиться, чтобы ключи были не именованные, а если забыл, то могут быть случайные совпадения ключей и наименований аргументов.
Дополнительно, при рефакторинге функции/метода, надо помнить о возможных входных данных и все это учитывать.
На мой взгляд php начал развиваться в не том направлении.
Слишком много уделяется внимание всяким бесполезным штучкам.
Взять нормальный функционал у одного языка, и сделать из него елку.