Geebrox

[ziggi]

Тут, наверное, мне стоило обобщить. О помодульном разделении не гласит не одна документация, связанная с применением pawn к разработке самп-проекта. Т.е. какой-то юзер открыл эту возможность, вследствие, её стали применять и другие.

Открою секрет - ни в одном из языков программирования в документации не пишут о паттернах разработки. Ты не найдёшь информацию об MVC в документации к PHP.

Делить проект на файлы - это обычное дело, призванное структуризировать код. Есть книга, где об этом хорошо написано - Совершенный код (Макконнелл).

P.S. Я бы не называл это "модулями". Ибо модули, как правило, можно отключать, при этом не терять работоспособность всего проекта. В SA-MP модулями можно назвать какие-нибудь FS, интегрированные с самим модом.

[DeimoS]

Тут, наверное, мне стоило обобщить. О помодульном разделении не гласит не одна документация, связанная с применением pawn к разработке самп-проекта. Т.е. какой-то юзер открыл эту возможность, вследствие, её стали применять и другие.

Ну тут Ziggi уже ответил тебе, сказав то, что я пытаюсь которое сообщение подряд тебе донести, так что промолчу.

Отчасти соглашусь. Но багфиксы и доработки сразу в нескольких модулях - фактически, одно и тоже. Это либо поправки, либо добавление/улучшение какой-то части некоего инклюда. Если мы будем осуществлять поиск среди всех модулей, то это будет примерно равнозначно поиску по всему моду. Да, небольшое превосходство модуля в этом есть, иной код не будет мешать. Но это всё лишь визуально, поэтому, тезис не слишком весомый, чтобы сразу переходить на разделение.

Поиск по модулям никоим образом не будет равносилен поиску по всему моду в том случае, если либо ты сам писал весь мод и продумывал модульность => ты чётко знаешь где и что находится, либо ты уже достаточно долго возился с модом и так же разобрался с тем, как реализована структура - суть одна: если ты знаешь структуру мода, ты легко найдёшь нужный тебе файл. А далее у тебя будет лишь код нужной тебе системы и небе не нужно будет по всему моду "летать" в поисках кусков нужной тебе системы с целью что-то в ней изменить.

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

Стоит добавить, что изначальное построение проекта, основанное на модулях - это одно, а вот перестроение уже полностью/частично готового проекта - другое, и наоборот.

Естественно это разные вещи. Часто перестроение готового проекта будет гораздо затратнее в плане сил, нежели если изначально писать мод, разбивая его на файлы. Тащемта, про это я говорил в одном из сообщений выше.

Я, наверное, больше сведусь к тому, что модули стоит применять частично, дабы адаптация под такой лад была у всех юзеров. 40-50% - модули, 50-60% - основной каркас мода. Тут и у самого автора проблем не возникнет, можно будет представить свой проект в плане отдельных текстовых файлов, и единым блоком. Довольно рациональное решение для всех, как по мне. Наверное, стоит закрепить свою позицию на данной отметке.

Ориентироваться под юзеров - не лучшая затея. Среднестатистический юзер не проч, если бы ты и названия все писал на транслите, и вообще прикрутил к компилятору поддержку кириллицы, чтоб весб код можно было целиком на русском писать. А так же вообще весь мод за него написал, ибо юзеру лень.
Если за тенденциями и следовать, то только за хорошими тенденциями, которые зародились не просто потому-что кто-то чего-то не знал, а потому что многие скриптеры пробовали сделать по разному, но, в итоге, пришли к одному, самому наилучшему варианту. Иначе сообщество так и останется в неокрепшем зародыше, где процветает транслит, массивы по 4096 ячеек и прочие распространённые "фишки".

P.S. Взять те же рекомендации, что есть на этом форуме. Зайди на п-и, поищи темы 2011-2013 годов и посмотри на код, который в них будет. Даже о самых банальных пунктах из рекомендации там не слышно и тогда такой стиль кодинга считался нормой. Если бы все придерживались тех же принципов: "Ну большинство же так делает, значит так и надо" - сейчас до сих пор бы "профессионалы" кодили так, как нынче даже нубам кодить стыдно должно быть. И может пример не самый удачный, ибо мне следовало бы конкретные ссылки предоставить, но суть в том, что "старое и распространённое" - не всегда "правильное и хорошее". Нужно уметь ставить под сомнение общепринятые истины, ибо часто эти истины ошибочны (Земля круглая/Все рыжие = ведьмы/Единоросы не победят на выборах и т.п.). Вооот

[Daniel_Cortez]

Я думаю, что почти все SA-MP моды/скрипты нелегальны, с лицензиями никто не заморачивается. Например, fixes.inc никто не может использовать, ибо там даже лицензии нет.

Что верно, то верно. Но упомянуть про несовместимость лицензии плагина MySQL со многими работами под MPL 1.1 (многие из которых принадлежат Y_Less'у), думаю, всё же стоило, ибо мало кто здесь знает об этом факте.

Касаемо случая с fixes.inc, остаётся только надеяться, что для этого инклуда удастся решить вопрос с перелицензированием.
Кстати, не мог бы отметить меня в списке согласных на смену лицензии в том самом issue на GitHub?

[Long-]

Открою секрет - ни в одном из языков программирования в документации не пишут о паттернах разработки. Ты не найдёшь информацию об MVC в документации к PHP.

Делить проект на файлы - это обычное дело, призванное структуризировать код. Есть книга, где об этом хорошо написано - Совершенный код (Макконнелл).

P.S. Я бы не называл это "модулями". Ибо модули, как правило, можно отключать, при этом не терять работоспособность всего проекта. В SA-MP модулями можно назвать какие-нибудь FS, интегрированные с самим модом.

Странно, а что модули нельзя отключать?Закомментировав этот модуль?(Допустим в нем лежит одна система).
В случае закомментирования этот модуль станет неактивен, а на работоспособность всего проекта это никак не повлияет (Лишь повлияет на ту систему которая была в модуле)

[ziggi]

Что верно, то верно. Но упомянуть про несовместимость лицензии плагина MySQL со многими работами под MPL 1.1 (многие из которых принадлежат Y_Less'у), думаю, всё же стоило, ибо мало кто здесь знает об этом факте.

Согласен, я сам этого не знал.

Кстати, не мог бы отметить меня в списке согласных на смену лицензии в том самом issue на GitHub?

Сделано.

Странно, а что модули нельзя отключать?Закомментировав этот модуль?(Допустим в нем лежит одна система).
В случае закомментирования этот модуль станет неактивен, а на работоспособность всего проекта это никак не повлияет (Лишь повлияет на ту систему которая была в модуле)

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

И да, здесь "модули" нельзя отключать: отключи систему аккаунтов/БД/что-либо ещё и всё перестанет работать (если вообще скомпилируется).

[Geebrox]

Что верно, то верно. Но упомянуть про несовместимость лицензии плагина MySQL со многими работами под MPL 1.1 (многие из которых принадлежат Y_Less'у), думаю, всё же стоило, ибо мало кто здесь знает об этом факте.

Касаемо случая с fixes.inc, остаётся только надеяться, что для этого инклуда удастся решить вопрос с перелицензированием.
Кстати, не мог бы отметить меня в списке согласных на смену лицензии в том самом issue на GitHub?

Касаемо GPL и MPL, хотел переписать a_mysql.inc под MPL и перелицензировать весь проект под MPL,
но со случаем fixes я ничего не могу предпринять.

- - - Добавлено - - -

И да, здесь "модули" нельзя отключать: отключи систему аккаунтов/БД/что-либо ещё и всё перестанет работать (если вообще скомпилируется).

я работаю над новой архитектурой проекта, возможно это будет исправлено

[DeimoS]

Что верно, то верно. Но упомянуть про несовместимость лицензии плагина MySQL со многими работами под MPL 1.1 (многие из которых принадлежат Y_Less'у), думаю, всё же стоило, ибо мало кто здесь знает об этом факте.

Касаемо случая с fixes.inc, остаётся только надеяться, что для этого инклуда удастся решить вопрос с перелицензированием.
Кстати, не мог бы отметить меня в списке согласных на смену лицензии в том самом issue на GitHub?

Это всё, конечно, здорово, но на деле кто вообще хоть раз заморачивался с лицензиями в SA-MP? Если сейчас нагрянуть на какой-нибудь крупный проект со словами: "Открывайте нам исходный код вашего мода, ибо вы используете инклуды под лицензиями, обязующими делать это" - нам просто в лицо посмеются и забанят. И ничего тут не поделать.

[Nexius_Tailer]

Так ведь он неодобряет использование модулей в том виде, в котором использует автор? Не одобряет. Неодобрение = осуждение

"в том виде, в котором использует автор" - уже видимо и сам соглашаешься, что речь о конкретной реализации

Я думаю, что почти все SA-MP моды/скрипты нелегальны, с лицензиями никто не заморачивается. Например, fixes.inc никто не может использовать, ибо там даже лицензии нет.

Кстати, лицензия ведь налагает какие-то обязательства или свободы, но раз её нет, то почему тогда это не может использоваться?)
Мне это немного народное творчество напоминает - у него лицензии тоже вроде как нет, и ограничений на распространении также не имеется. А fixes изначально позиционировался именно как фиксы от всего комьюнити, а не конкретного человека

[DeimoS]

"в том виде, в котором использует автор" - уже видимо и сам соглашаешься, что речь о конкретной реализации

Эмм, а если написать другой мод и оформить "модульность" в том же виде, то SooBad уже не будет против?
В своём сообщении он "против" активного разделения мода на кучу файлов: не зависимо от того, будет ли это "1 файл = 1 система" или "куча файлов = 1 система". Он пишет, что лучше отделять только определённые куски кода в отдельные файлы, а остальное писать в одном.
Это не речь о конкретной реализации, что придумал автор, а речь о разделении всего мода на файлы в целом.

[Daniel_Cortez]

Касаемо GPL и MPL, хотел переписать a_mysql.inc под MPL и перелицензировать весь проект под MPL,
но со случаем fixes я ничего не могу предпринять.

Звучит сомнительно хотя бы потому, что это всего лишь заголовочный файл? Что в нём такого можно переписать? Не говоря уже о возможных обвинениях в копировании чужого кода. Хотя вообще автор плагина обязан был применить лицензию GPL только к тем файлам, которые статически или динамически линковались с исходниками СУБД MySQL. К файлу a_mysql.inc такое требование не относится, т.к. он никак не линкуется к плагину - он всего лишь описывает интерфейс для виртуальной машиной AMX. В то же время в инклуде никакой лицензии нет, поэтому по умолчанию подразумевается та же лицензия, что и для всего плагина - GPL.
Советую обратиться к автору плагина MySQL или к текущему сопровождающему, чтобы узнать, попадает ли файл под действие GPL, чтобы устранить неопределённость с лицензией.

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

Возможно. Но они и не обязаны этого делать - они же не выкладывали в публичный доступ и не скидывали тебе лично *.amx от мода. А даже если и выкладывали, то могут особо не спешить - GPL предусматривает срок в 3 года на предоставление исходников.


UPD: Проверил, у плагина почему-то лицензия BSD - явно недосмотр со стороны разработчика плагина и ещё один повод спросить.