PDA

Просмотр полной версии : [Вопрос] Парсеры для модульных проектов



Geebrox
24.02.2018, 22:59
Всем привет. У меня возникла идея, а что если сделать парсеры для удобство работы с модульным проектом. В модульном проекте сложно запоминать все теги разных модулей или же запоминать имена функций, что отнимает время для поиска нужной функций или тега в других модулях чтобы вызвать их. Я создал простые парсеры, думаю можно довести до ума, но перед этим хотел бы узнать мнение других, как они будут относится такому подходу. Я попытаюсь объяснить принцып работы моих парсеров.


Как будет выглядить парсер:

ИмяМодуля:<действие:во_что_обращаться>НазваниеФункции(параметры_функции);

//пример: вызов функций из модуля аккаунтов:
AccountModule:<call:function>CreatePlayerData(playerid);

//пример: создание функции для модуля аккаунтов:
AccountModule:<create:function>CreatePlayerData(playerid) { /*тело функций*/ }

//пример: вызов колбэка из модуля админов:
AdminModule:<call:callback>OnAdminLogin(playerid);

//пример: создание колбэка для модуля админов:
AdminModule:<create:callback>OnAdminLogin(playerid) { /*тело колбэка*/ }
https://i.imgur.com/sNZYKPc.jpg
По моему было ясно суть данного парсера. Оно делает вызов или обращение к функциям/колбэкам логичнее. Просто взглянув в код можно будет узнать "зачем? | где? | почему? | как?".


Код самого парсера:

#define ACCOUNT_MODULE_TAG_FUNCTION: _accmfn_
#define ACCOUNT_MODULE_TAG_CALLBACK: _accmcb_

#define AccountModule:<%0:%1>%2(%3) accm@%0@%1(%2,%3)

#define accm@call@function(%0,%1) ACCOUNT_MODULE_TAG_FUNCTION:%0(%1)
#define accm@call@callback(%0,%1) ACCOUNT_MODULE_TAG_CALLBACK:%0(%1)

#define accm@create@function(%0,%1) stock ACCOUNT_MODULE_TAG_FUNCTION:%0(%1)
#define accm@create@callback(%0,%1) \
forward ACCOUNT_MODULE_TAG_CALLBACK:%0(%1);\
public ACCOUNT_MODULE_TAG_CALLBACK:%0(%1)


Это код только для модуля аккаунтов. Можно ещё и для других модулей так же создать свои парсеры. Но это ещё не конечная версия парсера, тут не учтено очень многое. Можно улучшить. А пока хотел бы узнать мнение остальных, как они будут оносится к такому коду, удобно ли это или наоборот усложняет написание кода, может улучшает читаемость или наоборот. Пишите ваши мнение, пожалуйста. И кстати для современных редакторов можно создать сниппеты чтобы сразу оформлять такой тип тегов.


Почему просто не использовать теги? Потому что как я уже описывал выше, теги (как по мне) не удобны. Их нужно создавать, создавать так чтобы они отличались от предыдущих и при это не теряли смысл (в парсерах можно назначить любой тег, но главное чтобы не совпадало с другими), так же нужно их запоминать, вспоминать и т.д.


Почему просто не называть функции смысловыми именами? Буду повторять, что нужно их запоминать/вспоминать, искать их если забыли название. А для тех кто занимается скриптингом не каждый день это трудно (носить в голове все имена функций, которые есть в огромном проекте, к примеру). Но с парсерами такого почти не будет, вы можете использовать те же имена колбеков или нативок, которых уже выучили за несколько лет/месяцев, они знакомы вам и вы не можете забыть их. (тот же OnPlayerConnect можно использовать в разных модулях).


Насчёт некоторых тонких моментов в самих парсерах, таких как зона видимости вызов через остальные скрипты, это можно доработать. Зона видимости охватит весь проект, можно сделать один парсер, который будет сам определять теги из названий функций. Короче говоря, это только скелет, можно довести до ума, но перед тем как потратить кучу времени. Нужно узнать мнение форумчан). Думаю вопросы про функциональности или недоделанности не возникнут, спасибо.


Вот несколько скринов, как будет выглядеть код:

С парсерами (https://imgur.com/a/WuPi3)
Без парсеров (https://imgur.com/a/deTfX)

Fallen A.
25.02.2018, 00:11
Лично мне данная идея пришлась по душе.

VVWVV
25.02.2018, 00:38
Но ведь это не парсеры, а обычные макро-функции (вот пример парсера (https://pastebin.com/9bdxezWr)). Сама идея хорошая, но из-за большого количества синтаксического сахара код раздувается.

Geebrox
25.02.2018, 00:41
Но ведь это не парсеры, а обычные макро-функции (вот пример парсера (https://pastebin.com/9bdxezWr)). Сама идея хорошая, но из-за большого количества синтаксического сахара код раздувается.

Понятно, я только начал их изучать. Так может и перепутал.