Вы невнимательно прочитали условие задания которое я написал. В глобальной области видимости «нет помойки» там один прозрачный функционал.
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В 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 .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.
2. Глобальные переменные
Вы путаете грешное с праведным. В том «что не вы утверждаете» имелось ввиду «не вносить в глобальную область видимости переменные разного функционала», так как опять таки сложно будет локализовать ошибки, да и не верно это просто логически. Так нет у меня «всего скопом». Пятый раз пишу… Чем глобальная область видимости хуже метода класса, в которой, в вашем фреймворк расположен код LAYOUT. А в SKY LAYOUT расположен в глобальной, и что тут не так?
1. Ошибки нужно не гасить, а устранять.
Это кто сказал? Почему все обязаны вам верить? По-видимому здесь на хабре пришли к такой мысли все… И это авторитетное мнение… Я не делал тестирование скорости работы @ если реально сильно медленное — можно в будущем устранить, а лучше пофиксить PHP, чтобы работало быстро. Если это рекомендация никогда не применять @ ввиду возможной запарки и создания себе сложной жизни и невозможности локализовать ошибку, — то это вопрос философский… Я ставлю подавление ошибок ТОЛЬКО в тех местах, где явно не будет проблем с локализацией ошибок, аналогично использую eval( ).
То что де-факто считается зло в сообществе людей с взглядом как у вас, дает ощутимые преимущества в краткости и простоте кода.
Я понимаю, что «много на себя беру» ставя под сомнение то, что eval и @ зло, как считается в вашем привычном кругу. Но на первом месте у меня не следование общепринятым нормам, а открытая логика. Я считаю, что если программист не может применить @ или eval( ) безошибочно, чтобы не сделать себе зло, то он и так не будет способен программировать, «делать вещи».
Реальное зло — оператор GOTO доказано математически и выброшено из всех языков программирования, eval же везде есть, так что это сомнительное зло.
Я попросил критику с аргументами. Разговариваю ровно так же как вы со мной. Если переборщил — извиняюсь. Я реально благодарен даже такой вашей критике.
Кстати, в симфони, есть отладочный модуль, который работает как веб-приложение, в режиме отладки, не помню как называется. Его по вашей логике нужно переделать в консоль?
Еще неплохо было бы все компьютерные игры портировать в консоль )
Ну вы сами себя слышите? Если есть разные опции… Есть возможность визуализировать процесс установки в браузере (это сапожник с сапогами), по вашему консоль удобнее? А как насчет установщика, например Drupal, который работает в браузере? Портировать в консоль? Вы скажете это не фреймворк, а приложение, у симфони шире область применения.
Ну прочтите определение для чего изобретен язык PHP — для работы с браузером, а то что он работает в консоле это дополнительная возможность, которая всегда идет номером два и не подразумевается что номера один нет.
И где же такие сервера, что PHP есть, а веб-сервера работающего на 80 порту нет?
SKY Framework это код для повторного использования для создания веб-приложений. Чувствуете де-факто определение? И каким макаром он не обязан работать с браузером? Это раз.
Приложение DEV.SKY., файл dev.php, от которого вы смотрите, де-факто предназначено для работы только! на рабочей станции программиста (чтобы вы поняли, это альтернатива консольной утилите от симфони и веб-приложению! Yii для генерации CRUD шаблонов). Кстати в Yii надо сделать del ему по вашей логике тоже. Это два.
Читайте статью «Нужны ли сапожнику сапоги?» http://ru.coresky.net/blog?id42 это три.
Совершенно аналогично вы можете в методе объекта создать лок. переменную, а потом забыть о ней и переопределить.
В 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 .=… вот такое добавление проанализировано мной на предмет того, что случайного кода быть не может.
Вы путаете грешное с праведным. В том «что не вы утверждаете» имелось ввиду «не вносить в глобальную область видимости переменные разного функционала», так как опять таки сложно будет локализовать ошибки, да и не верно это просто логически. Так нет у меня «всего скопом». Пятый раз пишу… Чем глобальная область видимости хуже метода класса, в которой, в вашем фреймворк расположен код LAYOUT. А в SKY LAYOUT расположен в глобальной, и что тут не так?
Это кто сказал? Почему все обязаны вам верить? По-видимому здесь на хабре пришли к такой мысли все… И это авторитетное мнение… Я не делал тестирование скорости работы @ если реально сильно медленное — можно в будущем устранить, а лучше пофиксить PHP, чтобы работало быстро. Если это рекомендация никогда не применять @ ввиду возможной запарки и создания себе сложной жизни и невозможности локализовать ошибку, — то это вопрос философский… Я ставлю подавление ошибок ТОЛЬКО в тех местах, где явно не будет проблем с локализацией ошибок, аналогично использую eval( ).
То что де-факто считается зло в сообществе людей с взглядом как у вас, дает ощутимые преимущества в краткости и простоте кода.
Я понимаю, что «много на себя беру» ставя под сомнение то, что eval и @ зло, как считается в вашем привычном кругу. Но на первом месте у меня не следование общепринятым нормам, а открытая логика. Я считаю, что если программист не может применить @ или eval( ) безошибочно, чтобы не сделать себе зло, то он и так не будет способен программировать, «делать вещи».
Реальное зло — оператор GOTO доказано математически и выброшено из всех языков программирования, eval же везде есть, так что это сомнительное зло.
Еще неплохо было бы все компьютерные игры портировать в консоль )
Ну вы сами себя слышите? Если есть разные опции… Есть возможность визуализировать процесс установки в браузере (это сапожник с сапогами), по вашему консоль удобнее? А как насчет установщика, например Drupal, который работает в браузере? Портировать в консоль? Вы скажете это не фреймворк, а приложение, у симфони шире область применения.
Ну прочтите определение для чего изобретен язык PHP — для работы с браузером, а то что он работает в консоле это дополнительная возможность, которая всегда идет номером два и не подразумевается что номера один нет.
И где же такие сервера, что PHP есть, а веб-сервера работающего на 80 порту нет?
Приложение DEV.SKY., файл dev.php, от которого вы смотрите, де-факто предназначено для работы только! на рабочей станции программиста (чтобы вы поняли, это альтернатива консольной утилите от симфони и веб-приложению! Yii для генерации CRUD шаблонов). Кстати в Yii надо сделать del ему по вашей логике тоже. Это два.
Читайте статью «Нужны ли сапожнику сапоги?» http://ru.coresky.net/blog?id42 это три.