Верно поняли. Я имел ввиду, что мою работу нужно корректировать. Знал и о композере и PHP FIG и глоб. области и о eval и что получу подобную реакцию здесь. Но не знал, что она повлияет на меня так. Это не значит, что я буду работать с симфони или подобным фреймворком. Ну не приемлет у меня душа этот современный подход… Буду искать альтернативные решения наверно, например, в сторону анализаторов кода, чтобы результат был не хуже чем: не пишем в глобальную область — значит 100% не получим ошибки такого типа, анализировать теорию и практику, между ними бывает пропасть.
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
Волевым решением сообщество решило не писать в глобальную область видимости. Но это одно из тех решений когда оно есть палка о двух концах. Решив одну проблему, оказалось что нужно писать больше кода и он стал сложнее для восприятия, думаю что также код стал более медленный (3 минуса)
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Конечно, мне ваше мнение интересно. Иначе зачем бы я делал сайт в том виде в каком он есть? Это проект для программистов.
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
52, 61 — это просто вручную посчитано кол-во элементов массива, он не меняется.
7 — пароль нормального уровня сложности, энтропии. Если хотите считайте начальный пароль, позже пользователь переопределит его.
23 — куки нормальной энтропии, чтобы не быть подобранной, но чтобы и не быть очень длинной
Эти цифры сейчас проставлены мной интуитивно. Идеально математически просчитать кол-во вариантов и выбрать.
Вы невнимательно прочитали условие задания которое я написал. В глобальной области видимости «нет помойки» там один прозрачный функционал.
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В SKY Framework с MVC паттерном, код приложения полностью размещается в методах класса и пользователь глобальную область не трогает. Кроме переменных в файле VIEW т.е. в main layout но они все с префиксами.
Еще аргумент: coresky это 45 кБ кода, подразумевается, что разработчик SKY полностью им владеет.
Практика: я несколько лет делаю сайты на SKY Framework — никаких проблем описываемых вами нет абсолютно. Справедливости ради скажу, более 10 лет назад, подобные проблемы были, но они несложно решались. И не так страшен рак как его малюют.
Я понимал, еще давно, что работая в глобальной области видимости я делаю лишний повод покритиковать себя. Но тривиальная простота кода и прозрачность перевесила в моем решении использовать такой подход.
До тестов пока дело не дошло, это сильно плохо, что я поспешил? Но планируется, только без phpunit. В SKY многие вещи кардинально отличаются от современного уже можно говорить «стандарта», поэтому без phpunit
Ну не нужен веб-сервер… это что панацея сделать так же? В SKY Framework всегда нужен, кроме консольных скриптов.
Объясните мне простую вещь: почему нельзя писать переменные в глоб. область видимости. Пусть в абстрактном языке. Если вы это сделаете — вы будете моим авторитетом. Мной овладеет глубокая печаль (кроме шуток) и я стану печально думать что делать с моей работой. Я не шучу!
Если ваш ответ: в глоб. области образуется помойка. Но сразу другой вопрос: а если в глоб. области переменные одного лишь функционала! Чем хуже она области видимости внутри метода класса??
Только прошу — логику. Ничего кроме нее. Ответ нельзя потому что все так говорят — не подходит.
Да почему же в штыки? Я нормально отвечаю, спрашиваю ). Хм, извините еще раз если вам так показалось. Тогда скажите, как вы среагируете на насмешливую критику, где вместо логичных доказательств идет просто опор на бренды и закостенелое мнение о вещах. А логика не учитывается.
Как я должен реагировать на ваши насмешливые посты? Как вы реагируете если бы оказались на моем месте? Если уличение от авторитетного источника — то понятно, и я так же. А если не от авторитетного? Разве я не толерантный? )
Вы меня простите, но я вас не знаю и вы мне не авторитет. Даже более того, я почти уверен что не авторитет. Авторитет для меня не тратил бы время на то, что тратите вы здесь. Это номер 1 и этого достаточно.
а должны обязательно?
https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F
testing — переводится как тестирование
deploy — развертывание приложения
phpunit — фреймворк для тестирования
а EXTR_SKIP обязательно всегда ставить? не знал. напишите разработчикам PHP — пусть намертво пофиксят.
Насчет PHP 7 — это серьезный прокол, не тестил. Обещаю в ближайшее время исправить. В этом проекте это задача номер 1. Если ничего не случится с моим свободным временем исправлю быстро. Но прошу вас меня понять: несмотря на то что coresky это 3 файла всего лишь размером 45 кБ, работы в проекте чрезвычайно много, а помощников у меня мало.
Для ответа на ваш вопрос нужно иметь результаты соревнования в скорости построения эквивалентных приложений, скорости их работы и простоты масштабирования новым функционалом. У вас такого нет, а то что вы написали — это только безосновательная догадка.
3. Определять что-то константами, и тем более проверять константы в файлах класса… Это в 2000 году было нормой
Иногда новое это хорошо забытое старое. А я считаю, что у нынешних трендов нет будущего. Потому как забрели «далеко в лес» играясь с разными вещами без оснований.
Как можно в eval «протащить» вирус, если код «под eval» конструируется другим кодом PHP который никак не связан с данными в БД? В index.php у меня есть eval(SKY_FRONT::PROC);
::PROC это вообще константа. Используется eval чтобы сократить код в index.php сделать его простым. ::PROC это стандартный константный код который нужен для построения сайтов.
<? eval($sky) ?> $sky это объект, тут используется __toString магический метод, чтобы вытянуть $sky->code, который генерируется таким образом, что там не может никак оказаться произвольный код, так как опять таки он состовляется из разных константных кусочков строк. Каждое $sky->code .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.
По моему мнению слишком большой ценой (увеличением, осложнением, меньшей производительностью, меньшей прозрачностью кода) мы со 100% вероятностью всего лишь гарантированно не получим ошибки одного типа. Это муха против бомбы можно сказать. Но я понимаю, что это может оказаться очень серьезно в самый неподходящий момент… В общем я в размышлениях пока что.
Обязательно хочу прочитать и сравнить свои мысли с первоисточником по поводу глоб. области, eval и @подавлении ошибок. Просто принять без осмысления наверно не смогу. В общем, мне сложно описать, что я чувствую сейчас и какой выберу путь, но спасибо вам за общение, оно было не зря однозначно. Если рассмешил — на здоровье, если отнял время — sorry.
Если выбрать другое решение — эти минусы стали плюсами. А граблей, которыми все пугают, пока не встречал, если все сделать аккуратно.
Я знал давно, многие вещи о которых вы говорите, о глобальной области и т.д. и сознательно их нарушил. Я хотел, чтобы вы посмотрели, чего можно достичь если нарушить их. А вы просто шлепнули меня ими. А чтобы увидеть чего можно достичь нужно более внимательно присмотреться к проекту, а не «одним глазом».
Посмотрите в историю: незыблемые стены тоже иногда рушатся, просто на все нужно свое время. А новое это часто хорошо забытое старое.
52, 61 — это просто вручную посчитано кол-во элементов массива, он не меняется.
7 — пароль нормального уровня сложности, энтропии. Если хотите считайте начальный пароль, позже пользователь переопределит его.
23 — куки нормальной энтропии, чтобы не быть подобранной, но чтобы и не быть очень длинной
Эти цифры сейчас проставлены мной интуитивно. Идеально математически просчитать кол-во вариантов и выбрать.
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В SKY Framework с MVC паттерном, код приложения полностью размещается в методах класса и пользователь глобальную область не трогает. Кроме переменных в файле VIEW т.е. в main layout но они все с префиксами.
Еще аргумент: coresky это 45 кБ кода, подразумевается, что разработчик SKY полностью им владеет.
Практика: я несколько лет делаю сайты на SKY Framework — никаких проблем описываемых вами нет абсолютно. Справедливости ради скажу, более 10 лет назад, подобные проблемы были, но они несложно решались. И не так страшен рак как его малюют.
Я понимал, еще давно, что работая в глобальной области видимости я делаю лишний повод покритиковать себя. Но тривиальная простота кода и прозрачность перевесила в моем решении использовать такой подход.
Ну не нужен веб-сервер… это что панацея сделать так же? В SKY Framework всегда нужен, кроме консольных скриптов.
Если ваш ответ: в глоб. области образуется помойка. Но сразу другой вопрос: а если в глоб. области переменные одного лишь функционала! Чем хуже она области видимости внутри метода класса??
Только прошу — логику. Ничего кроме нее. Ответ нельзя потому что все так говорят — не подходит.
Как я должен реагировать на ваши насмешливые посты? Как вы реагируете если бы оказались на моем месте? Если уличение от авторитетного источника — то понятно, и я так же. А если не от авторитетного? Разве я не толерантный? )
Вы меня простите, но я вас не знаю и вы мне не авторитет. Даже более того, я почти уверен что не авторитет. Авторитет для меня не тратил бы время на то, что тратите вы здесь. Это номер 1 и этого достаточно.
https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F
testing — переводится как тестирование
deploy — развертывание приложения
phpunit — фреймворк для тестирования
Удовлетворил знаниями?
https://ru.wikipedia.org/wiki/Goto
Насчет PHP 7 — это серьезный прокол, не тестил. Обещаю в ближайшее время исправить. В этом проекте это задача номер 1. Если ничего не случится с моим свободным временем исправлю быстро. Но прошу вас меня понять: несмотря на то что coresky это 3 файла всего лишь размером 45 кБ, работы в проекте чрезвычайно много, а помощников у меня мало.
А вы не в курсе? если не объявлена, — значит public
Иногда новое это хорошо забытое старое. А я считаю, что у нынешних трендов нет будущего. Потому как забрели «далеко в лес» играясь с разными вещами без оснований.
::PROC это вообще константа. Используется eval чтобы сократить код в index.php сделать его простым. ::PROC это стандартный константный код который нужен для построения сайтов.
<? eval($sky) ?> $sky это объект, тут используется __toString магический метод, чтобы вытянуть $sky->code, который генерируется таким образом, что там не может никак оказаться произвольный код, так как опять таки он состовляется из разных константных кусочков строк. Каждое $sky->code .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.