Глобальные переменные: зло или добро? (Продолжение)

Запись от CoderHuligan размещена 16.11.2018 в 11:27
Обновил(-а) CoderHuligan 16.11.2018 в 17:02

Непосредственно про глобальные переменные несколько ниже, а сейчас прелюдия.
Итак, в результате экспериментирования удалось преодолеть недостаток PHP, где он не может в переключателе switch делать include кода, в котором имеются операторы break, выдавая сообщение об ошибке.
Возможно что это и не недостаток, а способ реализации современных интерпретаторов, при котором даже инклюдить код в цикле на тоже самое место не получается.
Пытаясь ранее преодолеть этот недостаток я пришёл к выводу, что нужно оборачивать код в функцию и подключать эту функцию в switch. А в этой функции вместо break делать return в нужных точках кода. Напомню, что реализуется автомат. К тому же с глобальными переменными. Об этом ниже.
Но, применение функций вместо просто кода имеет свои ограничения чисто архитектурного плана, да и в виде функционала! И это крупный недостаток такого костыля, ибо по другому это не назовёшь!
Однако! Выход всё же нашёлся, и как всё гениальное он оказался очень простым! Как только я сразу об этом не догадался просто диву даёшься..
Итак имеем автомат:

PHP

$State=$Action;
while($State!='exit')
{
    switch ($State)
    {
        case 'activatePage':
            include(MODULES.'registration/activate/activate_page.php');
        break;
        case 'agreementPage':
            include(MODULES.'registration/agreement/agreement_page.php');
        break;
        default:
            $State='exit';
    }
}

остальные case не показаны, чтобы не загромождать.
В инклюде имеем:

PHP

if (!defined('SOMELABEL_OK')){die('Access denied!');}
 
//если нужно перейти в другое состояние
//то мы присваиваем 
$State='some_state';
//и делаем return из инклюда:
return;
//дальше много другого кода

PHP это позволяет делать без применения функций как таковых, и это отнюдь не хак, а задокументированная возможность, которой многие пользуются.
Итак, развлекуха продолжается! А если серьёзно, то продолжается НОРМАЛЬНЫЙ кодинг проекта. Если бы я программировал в традиционном стиле, то мне пришлось бы потратить на это дело в 10 раз больше времени, так как кодить в таком стиле это сущее облегчение. Здесь всё под рукой, все переменные, разделение ответственности происходит на уровне соглашений имён. Можно реализовать даже АРХИ-сложный алгоритм без излишнего напряжения мозгов. Функционал движка будет значительно расширен, он будет просто намного умнее своих предшественников. Также будет реализована возможность по самолечению кода, что отсутствует в других реализациях. Автомат позволяет сделать всё, что хочешь.

Возвращаясь к теме глобальных переменных.
Так зло они или добро? Давайте, наконец попытаемся на него ответить.
Большинство специалистов считают, что зло. Даже я так считал, правда с натяжкой. для некоторые переменных всё-таки лучше иметь ограниченную область видимости. Сейчас я всё более склоняюсь к более открытой реализации системы.
Понимаете, переменные это ДАННЫЕ в чистом виде. Они то, с чем РАБОТАЮТ, а не то что работает. Это первое. Должны ли данные принадлежать глобальной видимости?
Если мы стремимся к компонентной системе, то каждый компонент в той или иной степени должен в перспективе иметь полный доступ к любой области данных. Практика показывает, что очень часто компоненту требуется доступ к самым разным данным, которые, в общем случае, принадлежат разным сферам ответственности.
При традиционном кодинге приходится делать рефакториниг проекта, чтобы изменить архитектуру или функционал. Если бы данные обще-разделялись, то такой проблемы бы не было.
Не надо было бы постоянно ломать голову над тем, каким образом передать параметр из одной области в другую. А ведь, иногда эти области очень далеки друг от друга и хорошо замаскированы..
Конечно, скажут, но ведь это говнокодинг, так все считают. Ну и пусть считают. и работают в командах. Я в команде не работаю, а работаю один, а когда работаешь один то приходится учитывать такую вещь как фактор времени. Мне некогда заниматься головоломками, пусть этим занимаются те, кто получает стабильную зарплату, которая зависит от того, сколько времени вы потратили на проект в сторону увеличения.. Индусы знают.. А я один должен быть эффективнее целой команды!
И мне надо кодить, и кодить БЫСТРО, а самое главное ЭФФЕКТИВНО. Ведь тот же пых это интерпретатор, хотя сейчас его и разогнали благодаря байт-коду и виртуальной машине.
Области ответственности глобальных данных прописываются в ДОКУМЕНТЕ! Что большинство не умеет и не любит делать.. Учили-то не тому..
Возвращение к родимому бейсику? Да, да, да! И это круто!

Размещено в Без категории

Показов 2177 Комментарии 17

« Плоский код, как возвращение к Машине Тьюринга Главная страница Строковая библа на Си. »

Всего комментариев 17

Комментарии

	Цитата: Возвращение к родимому бейсику? Причем здесь бейсик?
	Запись от locm размещена 16.11.2018 в 15:10

	Цитата: Глобальные переменные: зло или добро? (Продолжение) Когда премию дадут за этот скандальный репортаж прямо из зAда?
	Запись от Avazart размещена 16.11.2018 в 16:01 Обновил(-а) Avazart 16.11.2018 в 16:04

Цитата:

Сообщение от locm

Причем здесь бейсик?

При том, что первые бейсики были неструктурными.Там был оператор goto, которым и оперировали, и, кстати, реализовывали правильные алгоритмы, ибо не знали о таком понятии, как "структурное программирование". То есть реализовывали то, что требовалось задачей, не больше и не меньше того.. Там были ТОЛЬКО глобальные переменные и вообще не было функций и процедур. Это потом уже ввели процедуры gosub. Первоначально всё реализовывалось на одном листинге. Это конечно плохо с ростом программы, однако здравое зерно там было..
Самое главное, что всё это позволяет получить Свободу.
Вы забыли о свободе самовыражения, ведь нужно придерживаться каких-то принципов, соглашений и пр. Коллеги не поймут. Потребителю от этого ни горячо ни холодно: им нужно чтобы программа хорошо работала, и всё.
Сейчас новички начинают не с бейсиков, а с питонов и хаскелей, и их мозги уже неисправимы..

Запись от CoderHuligan размещена 16.11.2018 в 17:13 CoderHuligan вне форума

Цитата:

Сообщение от CoderHuligan

При том, что первые бейсики были неструктурными.

Бейсик был одним из первых ЯВУ. Неудивительно что он в те времена был неидеален.

Цитата:

Сообщение от CoderHuligan

Там был оператор goto, которым и оперировали

Который до сих пор есть в C/C++ и его используют.

Цитата:

Сообщение от CoderHuligan

не знали о таком понятии, как "структурное программирование"

Вероятно дело в другом. Ресурсы первых компов были очень скромными и на первые ЯВУ сильно влиял ассемблер.

Цитата:

Сообщение от CoderHuligan

Это потом уже ввели процедуры gosub

Gosub это вызов подпрограммы и к процедурам/функциям отношения не имеет. Это аналог ассемблерного Call с возвратом по Return (не путать с одноименным сишным оператором).

Но даже на современном диалекте бейсика я могу написать что-то типа.

PureBasic

y=2
Gosub Calc
Debug x
End
 
Calc:
x = y * 2
Return

И это будет работать.

Кликните здесь для просмотра всего текста

Только так писать можно очень простые программы. По нормальному, лучше использовать процедуры/функции, пространства имен и т. д.

Запись от locm размещена 16.11.2018 в 22:59 locm вне форума

Обновил(-а) locm 16.11.2018 в 23:01

Цитата:

Сообщение от locm

Неудивительно что он в те времена был неидеален.

Ещё надо посмотреть, что считать "идеальностью".. Конечно он был не идеален, но не из-за того, что не имел структурных операторов, а из-за того, что вообще не имел никакого понятия о какой-либо парадигме.

Цитата:

Сообщение от locm

Который до сих пор есть в C/C++ и его используют.

В курсе. Сам его там использую. В си есть даже указатели на метки(в gcc).
Системный язык не может без этого.

Цитата:

Сообщение от locm

Gosub это вызов подпрограммы и к процедурам/функциям отношения не имеет.

Да, это так.

Цитата:

Сообщение от locm

По нормальному, лучше использовать процедуры/функции, пространства имен и т. д.

Эх..
По нормальному нужен особый язык!..
А сейчас, то то не так, то другое. Приходится подстраиваться.. Вот, я вчера написал про то, что кодинг продолжается. Он действительно продолжается, однако, придётся всё-таки использовать функции вместо просто инклюдов. Причина? Причина в том, что мне нужен расширяемый проект, что-то типа data-driven programming(кому интересно, в гугл), где логика в основном определяется конфигами. Я могу прописать в конфиге вызов какой-то процедуры в каком-то файле, а код это выполнит. И если мне нужно удалённо пользователю прислать плагин, то этот плагин автоматически пропишется в системе не меняя существующего кода. Юзеру нужно будет лишь нажать одну кнопку с инсталяцией. А если плагин нужно деинсталировать, то он сам деинсталируется выписав себя из всех конфигов. Если инклюдить прямо в switch, то придётся всё прописывать прямо в коде, а это не айс, по крайней мере в данном проекте(я пишу форумный движок). Придётся использовать чисто компонентную модель. А автоматы создавать прямо в функциях. Это конечно сильно ослабит проект, но хотя бы он будет понятен другим программистам если те захотят присоединится к его развитию, а я на это надеюсь.
Мне самому интересно что из этого выйдет. Но что-то должно выйти, ведь ядро практически готово, а там уже легче: только наращивай функционал.

Запись от CoderHuligan размещена 17.11.2018 в 10:23 CoderHuligan вне форума

Обновил(-а) CoderHuligan 17.11.2018 в 13:29

	Цитата: По нормальному нужен особый язык!.. Шутка ли, совпадение ли, но я такие фразы слышу исключительно от разного рода товарищей, которые ни одного языка толком не знают и любят свои собственные переизобретать.
	Запись от Usaga размещена 18.11.2018 в 07:42

Нет, такие утверждения ещё слышны от изобретателей вечных двигателей, плоской земли, антигравитации, энергии вакуума и эфира, и прочих недоучек а-ля "Все учёные вам лгут! Только я, неосилятор школьного курса, покажу вам истинный путь и правду!"

Запись от Rius размещена 18.11.2018 в 09:28 Rius вне форума

	Это и есть "разного рода товарищи" в моём понимании)
	Запись от Usaga размещена 18.11.2018 в 09:54

Ну вы то все конечно "осиляторы", которые что-то осилили и теперь считаете всех несогласных неосилянтами. Удобная позиция я вам скажу. Сидеть в своём болоте и оттуда квакать, очень приятно, ведь болото такое тёплое да ещё и кормит.. Пена индустрии.

Запись от CoderHuligan размещена 18.11.2018 в 10:22 CoderHuligan вне форума

	К слову, "неосиляторы" от науки огрызаются иначе - "всё это засланцы нефтеиндустрии, злопыхатели и завистники!". Или просто игнорят и дальше гонят пургу. Ведь денежка за просмотры на YouTube им капает, а это - главное.
	Запись от Rius размещена 18.11.2018 в 10:35

	Но мне-то денежка не капает и это не главное для меня. Мне ближе поиск истины, где бы она не находилась. И ваша наука об очень многом любит умалчивать, а народу предлагать её суррогат.
	Запись от CoderHuligan размещена 18.11.2018 в 11:22

	Это тоже довольно обычный ответ тех, кто до монетизации ещё не дошёл.
	Запись от Rius размещена 18.11.2018 в 11:27

	Это обычный ответ тех, кто говорит о своём хобби. Однако всё может случится и хобби превратится в монетизацию.
	Запись от CoderHuligan размещена 18.11.2018 в 11:35

	Есть ниши которые ещё не заняты, но я вам об этом не скажу..
	Запись от CoderHuligan размещена 18.11.2018 в 11:37

	1000 и 1 способ развести лохов... Не надо.
	Запись от Rius размещена 18.11.2018 в 11:47

Цитата:

Мне ближе поиск истины, где бы она не находилась.

Если бы это было действительно так, то вы бы не хаяли результаты этих поисков, проведённых другими, а попытались бы вникнуть. А так получается, что сами даже не пытались разобраться, но уже уверены, что вокруг одно дерьмо. Классный поиск истины, ничего не скажешь.

Цитата:

И ваша наука об очень многом любит умалчивать

А вы какую науку практикуете?) Нибиру-edition?

Запись от Usaga размещена 19.11.2018 в 08:58 Usaga вне форума

	Цитата: Есть ниши которые ещё не заняты, но я вам об этом не скажу.. Вы про велосипедостроение (DCASF, Яр и прочие зета минус минус) ?
	Запись от Usaga размещена 19.11.2018 в 09:00

Сообщение форума

Отменить изменения

Архив
< Ноябрь 2024
Вс	Пн	Вт	Ср	Чт	Пт	Сб
20	21	22	23	24	25	26
27	28	29	30	31	1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30