[Include] key_pickupfix.inc [Архив] - Pro Pawn - Портал о PAWN-скриптинге

whale

14.04.2018, 13:56

Описание:

Данный инклуд был написан с целью устранить всем известную проблему повторного подбора пикапа посредством использования клавиши (как, в принципе, можно было догадаться из названия). То есть, встав на пикап, Вам нужно нажать заданную клавишу для его срабатывания.

Преимущества реализации:

• В данной реализации не используются динамически зоны, перехват функций создания пикапов, сравнения расстояния, etc.

• По умолчанию пикапы срабатывают обычным способом. Существует 2 функции для создания пикапов, которые будут срабатывать на кнопку (каждому пикапу можно задать определённую клавишу для срабатывания).

• Поддержка Streamer plugin от Incognito.

Пример:

#define KEY_PICKUPFIX_USED_KEY KEY_WALK // Данный макрос существует для двух функций представленных ниже.
#include <key_pickupfix.inc>

Функция

Описание

Возвращает

key_CreatePickup(model, type, Float:X, Float:Y, Float:Z, virtualworld = 0, usedkey = KEY_PICKUPFIX_INVALID_USED_KEY)
Создаёт статический пикап, который срабатывает на кнопку, если указан параметр usedkey (ID кнопки, на которую будет срабатывать пикап), либо объявлен макрос KEY_PICKUPFIX_USED_KEY.
ID созданного пикапа.

key_CreateDynamicPickup(modelid, type, Float:x, Float:y, Float:z, worldid = -1, interiorid = -1, playerid = -1, Float:streamdistance = STREAMER_PICKUP_SD, STREAMER_TAG_AREA areaid = STREAMER_TAG_AREA -1, priority = 0, usedkey = KEY_PICKUPFIX_INVALID_USED_KEY)
Создаёт динамический пикап, который срабатывает на кнопку, если указан параметр usedkey (ID кнопки, на которую будет срабатывать пикап), либо объявлен макрос KEY_PICKUPFIX_USED_KEY.
ID созданного пикапа.

Автор: whale (a.k.a Twixxx/Twixyck)
Исходный код: https://pastebin.com/2EJUC02j

История версий:

• 14.04.2018 | v1.0 - Релиз.
• 15.04.2018 | v1.1 - Добавлена совместимость статического перечисления со старыми версиями компилятора.
• 16.04.2018 | v1.2 - Теперь, по умолчанию, не все пикапы срабатывают на кнопку. Для создания пикапов по кнопке существует 2 функции:
key_CreatePickup - для статических пикапов и key_CreateDynamicPickup - для динамических пикапов соответственно (см. более подробную информацию в представленной таблице выше).
• 22.04.2018 | v1.2.1 - Убран знак подчёркивания ("_") у префикса. Добавлен префикс для перечислений.
• 22.04.2018 | v1.2.2 - Исправлена несовместимость с последней версией streamer`а.

Kovshevoy

14.04.2018, 15:10

Чето я делаю не так х)
Подключал и после streamer`a, и перед ним.

https://i.imgur.com/nocZkmv.png

whale

14.04.2018, 15:20

Чето я делаю не так х)
Подключал и после streamer`a, и перед ним.

https://i.imgur.com/nocZkmv.png

Проверял на 2-ух игровых модификациях, всё исправно. Попробуй подключить к другому игровому моду/с другим компилятором (я использовал данный компилятор: http://pro-pawn.ru/showthread.php?2207-Pawn-compiler-%283-10%29&p=88828&viewfull=1#post88828).

Kovshevoy

14.04.2018, 15:30

Проверял на 2-ух игровых модификациях, всё исправно. Попробуй подключить к другому игровому моду/с другим компилятором (я использовал данный компилятор: http://pro-pawn.ru/showthread.php?2207-Pawn-compiler-%283-10%29&p=88828&viewfull=1#post88828).

С другим компилятором у меня вылетают другие ошибки, привык уже работать с этим
А ещё, ты чу-чуть убрать забыл с исходника инфу:

This include replaces Kick, Ban and BanEx functions with its own versions
that call original functions with a 0.5-second delay.
You can set the delay time by defining DC_KICKFIX_INTERVAL macro
before the #include line.

whale

14.04.2018, 15:33

С другим компилятором у меня вылетают другие ошибки, привык уже работать с этим
А ещё, ты чу-чуть убрать забыл с исходника инфу:

This include replaces Kick, Ban and BanEx functions with its own versions
that call original functions with a 0.5-second delay.
You can set the delay time by defining DC_KICKFIX_INTERVAL macro
before the #include line.

Предоставь ошибки, попробуем разобраться. По поводу исходника – спасибо. Брал лицензию из инклуда Кортеза, видимо не досмотрел, исправлю.

Kovshevoy

14.04.2018, 15:37

Предоставь ошибки, попробуем разобраться. По поводу исходника – спасибо. Брал лицензию из инклуда Кортеза, видимо не досмотрел, исправлю.

Убрал с enum e_PLAYER_PICKUP_DATA "static", ошибки пропали. Как видишь, скомпилировало

https://i.imgur.com/ZekjY6m.png

whale

14.04.2018, 15:42

Убрал с enum e_PLAYER_PICKUP_DATA "static", ошибки пропали. Как видишь, скомпилировало

https://i.imgur.com/ZekjY6m.png

Исправил, благодарю.

Kovshevoy

14.04.2018, 15:48

Исправил, благодарю.

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

whale

15.04.2018, 17:19

Если есть какие-либо советы/замечания по поводу кода - буду рад услышать критику :)

whale

16.04.2018, 00:43

UPD v1.1: Добавлена совместимость статического перечисления со старыми версиями компилятора.

DeimoS

16.04.2018, 12:08

whale

16.04.2018, 12:52

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

И кто учил составлять такие условия?

if(gettime() - _key_pickupfix_playerPickupData[playerid][_key_pickupfix_pickupTimestamp] <= 1)
Почему нельзя просто сравнить gettime и значение переменной? Для чего там вычисления лишние?

1) Ты имеешь ввиду функцию создания пикапа с перехватом, которая будет закреплять за пикапом информацию, используется ли клавиша в данном пикапе и если да - то какая? А если же клавиша не будет использоваться - тогда сам фикс повторного подбора теряет смысл, нет? В таком случае придётся применять ещё какой-то вариант (те же динамические зоны) к пикапам, которые не используют клавишу. Или я ошибаюсь?

2) Немного не понял тебя (объясни: что ты имел ввиду?). Данное условие проверяет нажатие клавиши в течении 1-ой секунды.

DeimoS

16.04.2018, 13:04

1) Ты имеешь ввиду функцию создания пикапа с перехватом, которая будет закреплять за пикапом информацию, используется ли клавиша в данном пикапе и если да - то какая? А если же клавиша не будет использоваться - тогда сам фикс повторного подбора теряет смысл, нет? В таком случае придётся применять ещё какой-то вариант (те же динамические зоны) к пикапам, которые не используют клавишу. Или я ошибаюсь?

Я имею ввиду добавление необязательного параметра для функции создания пикапа, который будет хранить в себе ID клавиши, которую нужно нажать для подбора пикапа.
Соответственно, при обработке пикапа, если никакая клавиша не закреплена за пикапом, то сразу пропускаем код обработки пикапов на кнопку и переходим к обработке обычных пикапов, тем самым пропуская кучу лишних действий, которые у тебя сейчас прописаны в том же OnPlayerPickUpPickup.
Ну а про то, что на выходе получаем возможность закрепления конкретного пикапа за конкретной кнопкой, а не общей для всех, думаю, и так понятно.

2) Немного не понял тебя (объясни: что ты имел ввиду?). Данное условие проверяет нажатие клавиши в течении 1-ой секунды.

В твоём условии сначала произойдёт получение значений gettime и переменной, потом произойдёт вычитание и только потом произойдёт сравнение с единицей.

Хотя можно просто сделать так:

if(gettime() < _key_pickupfix_playerPickupData[playerid][_key_pickupfix_pickupTimestamp])
И на выходе получим тот же результат, только, при этом, мы просто получим значения gettime/переменной, а после сразу сравним их, чем уменьшим количество лишних инструкций.

whale

16.04.2018, 13:12

Я имею ввиду добавление необязательного параметра для функции создания пикапа, который будет хранить в себе ID клавиши, которую нужно нажать для подбора пикапа.
Соответственно, при обработке пикапа, если никакая клавиша не закреплена за пикапом, то сразу пропускаем код обработки пикапов на кнопку и переходим к обработке обычных пикапов, тем самым пропуская кучу лишних действий, которые у тебя сейчас прописаны в том же OnPlayerPickUpPickup.
Ну а про то, что на выходе получаем возможность закрепления конкретного пикапа за конкретной кнопкой, а не общей для всех, думаю, и так понятно.

В твоём условии сначала произойдёт получение значений gettime и переменной, потом произойдёт вычитание и только потом произойдёт сравнение с единицей.

Хотя можно просто сделать так:

if(gettime() < _key_pickupfix_playerPickupData[playerid][_key_pickupfix_pickupTimestamp])
И на выходе получим тот же результат, только, при этом, мы просто получим значения gettime/переменной, а после сразу сравним их, чем уменьшим количество лишних инструкций.

1) Хорошо, попробую реализовать в ближайшее время.
2) Поставил твоё условие - перестало работать. В твоём условии идёт проверка на то, меньше ли gettime() чем время в переменной, а в моём условии идёт проверка на то, что промежуток между двумя этими значениями меньше или равен 1.

DeimoS

16.04.2018, 13:49

Поставил твоё условие - перестало работать. В твоём условии идёт проверка на то, меньше ли gettime() чем время в переменной, а в моём условии идёт проверка на то, что промежуток между двумя этими значениями меньше или равен 1.

Ну так а при каком условии промежуток будет меньше или равен 1? Если значение одного из членов условия больше другого, не?

12-11 // 12 больше 11 на 1, что совпадает с условием
15-11 // 15 больше 11 на 4, что совпадает с условием
21-11 // 15 больше 11 на 10, что совпадает с условием
10-11 // 11 меньше 11 на 1, что НЕ совпадает с условием
В первых трех случаях второй член меньше первого и если первый член меньше второго, условие не сработает.
А танцы с вычислением нужны были бы только в том случае, если тебе нужно было бы выполнять код только для конкретного диапазона значений.

Раз не работает, замени "<" на ">" и должно всё заработать. Я не вчитывался особо в твой код и не смотрел какой из членов условия должен быть больше для работы кода.

whale

16.04.2018, 14:15

Ну так а при каком условии промежуток будет меньше или равен 1? Если значение одного из членов условия больше другого, не?

12-11 // 12 больше 11 на 1, что совпадает с условием
15-11 // 15 больше 11 на 4, что совпадает с условием
21-11 // 15 больше 11 на 10, что совпадает с условием
10-11 // 11 меньше 11 на 1, что НЕ совпадает с условием
В первых трех случаях второй член меньше первого и если первый член меньше второго, условие не сработает.
А танцы с вычислением нужны были бы только в том случае, если тебе нужно было бы выполнять код только для конкретного диапазона значений.

Раз не работает, замени "<" на ">" и должно всё заработать. Я не вчитывался особо в твой код и не смотрел какой из членов условия должен быть больше для работы кода.

В том то и дело, что диапазон должен быть от 0 секунд до 1 секунды. В твоём случае код будет выполняться таким образом, что даже если я встану на пикап и нажму указанную кнопку спустя 5-10 секунд - код пикапа сработает.

DeimoS

16.04.2018, 14:18

В том то и дело, что диапазон должен быть от 0 секунд до 1 секунды. В твоём случае код будет выполняться таким образом, что даже если я встану на пикап и нажму указанную кнопку спустя 5-10 секунд - код пикапа сработает.

Эмм, я тебя огорчу, но твоё условие работает для диапазона: "от ∞ до 1". Оно включит в себя все отрицательные значения. Соответственно, оно сработает только в том случае, если в переменной _key_pickupfix_pickupTimestamp значение будет больше, чем значение "gettime". Хотя если тебе так хочется включить в условие единицу, то "больше или равно".

whale

16.04.2018, 23:43

UPD v1.2: Теперь, по умолчанию, не все пикапы срабатывают на кнопку. Для создания пикапов по кнопке существует 2 функции:
key_CreatePickup - для статических пикапов и key_CreateDynamicPickup - для динамических пикапов соответственно (см. более подробную информацию в представленной таблице на первой странице).

DeimoS

17.04.2018, 05:55

При выборе цветов советую думать ещё и о тёмной стороне теме форума, а не только о светлой :)

https://i.imgur.com/m3oEiXj.png

whale

17.04.2018, 10:50

При выборе цветов советую думать ещё и о тёмной стороне теме форума, а не только о светлой :)

https://i.imgur.com/m3oEiXj.png

Учту. Сегодня займусь этим :)

Kovshevoy

18.04.2018, 09:48

Антифлуд будешь реализовывать? А то можно же огромное кол-во раз тыкать клавишу и пикап будет флудить.
С выбором времени например для использования пикапа можно похимичить

Daniel_Cortez

21.04.2018, 15:56

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

Касаемо реализации инклуда:
Намерение использовать префиксы для всего и вся, чтобы избежать коллизий имён, похвально, но не совсем понятно, зачем нужен знак подчёркивания "_" в самом начале префикса "_key_pickupfix_". Разве без этого знака "key_pickupfix_" будет мало? Префиксы - это, конечно, хорошо, но важно также и не переусердствовать.

В названиях перечислений (e_PLAYER_PICKUP_DATA, e_PLAYER_PICKUP_DATA) нет префиксов.

Если для констант и функций соблюдается тот же стиль именования, как в инклудах SA-MP (т.е. названия констант большими буквами, функций - в CamelCase), то почему названия перечислений (которые по сути являются тегами) записываются большими буквами, как константы? (пример тега из SA-MP: PlayerText)

Непостоянство в стиле задания квалификатора static:

static
_key_pickupfix_playerPickupData[MAX_PLAYERS][e_PLAYER_PICKUP_DATA];

static const NULL_PLAYER_PICKUP_DATA[e_PLAYER_PICKUP_DATA] = {KEY_PICKUPFIX_INVALID_PICKUP_ID, KEY_PICKUPFIX_PICK_TYPE_INVALID, 0, false};

Вообще в чём профит переносить всё, что после static или new, на новую строку? Нет, я правда хочу знать, потому что по мне это просто быссмысленная трата вертикального пространства, ухудшающая читаемость.

Строки в вызовах CallLocalFunction() можно сделать упакованными, чтобы занимали меньше места в памяти.
Строка со спецификаторами "dd" и вовсе дублируется 3 раза, можно объявить её один раз как именованный массив.

static const key_pickupfix_str_dd[] = !"dd";

Kovshevoy

21.04.2018, 16:04

Никогда бы не подумал, что этим неподдерживаемым старьём ещё кто-то пользуется. Нужно будет как-нибудь в репо компилятора Zeex'а поднять issue на счёт добавления мультиязычности.

Ну, твой с Тракером компилятор я использую уже давно, иногда бывают моменты с рекурсией, Ваш компилятор это спокойно отлавливает, не говоря про обычный стандартизированный. Ну и плюс, русификация же. Было бы круто, если реализуете новую версию (которой скорей всего не будет)

whale

21.04.2018, 16:41

Никогда бы не подумал, что этим неподдерживаемым старьём ещё кто-то пользуется. Нужно будет как-нибудь в репо компилятора Zeex'а поднять issue на счёт добавления мультиязычности.

Касаемо реализации инклуда:
Намерение использовать префиксы для всего и вся, чтобы избежать коллизий имён, похвально, но не совсем понятно, зачем нужен знак подчёркивания "_" в самом начале префикса "_key_pickupfix_". Разве без этого знака "key_pickupfix_" будет мало? Префиксы - это, конечно, хорошо, но важно также и не переусердствовать.

В названиях перечислений (e_PLAYER_PICKUP_DATA, e_PLAYER_PICKUP_DATA) нет префиксов.

Если для констант и функций соблюдается тот же стиль именования, как в инклудах SA-MP (т.е. названия констант большими буквами, функций - в CamelCase), то почему названия перечислений (которые по сути являются тегами) записываются большими буквами, как константы? (пример тега из SA-MP: PlayerText)

Непостоянство в стиле задания квалификатора static:

static
_key_pickupfix_playerPickupData[MAX_PLAYERS][e_PLAYER_PICKUP_DATA];

static const NULL_PLAYER_PICKUP_DATA[e_PLAYER_PICKUP_DATA] = {KEY_PICKUPFIX_INVALID_PICKUP_ID, KEY_PICKUPFIX_PICK_TYPE_INVALID, 0, false};

Вообще в чём профит переносить всё, что после static или new, на новую строку? Нет, я правда хочу знать, потому что по мне это просто быссмысленная трата вертикального пространства, ухудшающая читаемость.

Строки в вызовах CallLocalFunction() можно сделать упакованными, чтобы занимали меньше места в памяти.
Строка со спецификаторами "dd" и вовсе дублируется 3 раза, можно объявить её один раз как именованный массив.

static const key_pickupfix_str_dd[] = !"dd";

Благодарю за критику. Учту моменты, описанные тобою выше.
По поводу переноса на новую строку после объявления - честно говоря, для меня это добавляет читабельность, особенно, когда переменных несколько. Возможно, это не лучшая практика и я ошибаюсь.

Nexius_Tailer

21.04.2018, 20:47

Строка со спецификаторами "dd" и вовсе дублируется 3 раза, можно объявить её один раз как именованный массив.

static const key_pickupfix_str_dd[] = !"dd";

Это уже рил что-то из разряда извращений

Daniel_Cortez

22.04.2018, 00:58

Это уже рил что-то из разряда извращений
Не вижу в этом ничего плохого. Довольно старый приём, использующийся для рационального расхода памяти, в том числе для исключения дублирования строк в памяти скрипта (sscanf2 (https://github.com/maddinat0r/sscanf/blob/master/sscanf2.inc#L57-L63), fixes.inc (https://github.com/Open-GTO/sa-mp-fixes/blob/master/fixes.inc#L9939-L9940), TDW Vehicle (https://github.com/tdworg/samp-include-vehicle/blob/edc89c66a7741d60a57400d91d9f6ed0cad2bfef/tdw_vyengine.inc#L102), YSI (https://github.com/pawn-lang/YSI-Includes/blob/e67987f827907f291aee2ff08a980c6657ffd635/YSI_Internal/y_distribute.inc#L197)).

иногда бывают моменты с рекурсией, Ваш компилятор это спокойно отлавливает
В форке Zeex'а (http://pro-pawn.ru/showthread.php?2207-Pawn-compiler-%283-10%29) такое тоже возможно с помощью ключа -R.

Было бы круто, если реализуете новую версию (которой скорей всего не будет)
С учётом всех изменений, которые произошли в форке Zeex'а за последние несколько лет (а именно на этом форке и основывается ruspawncc), проще в тот форк добавить нормальную поддержку мультиязычности. Что я и собираюсь в ближайшем будущем сделать, устное согласие от Tracker1 (ему по идее принадлежит частичное авторство над переведёнными сообщениями в ruspawncc) уже получено.

Возможно, это не лучшая практика и я ошибаюсь.
Или ошибаюсь я, ибо многие популярные инклуды (взять хотя бы те, которые я перечислил парой цитат выше) тоже не грешат переносами после квалификаторов static, new, stock и т.д. Возможно, просто дело вкуса и не стоит заострять внимание на этом.

Nexius_Tailer

22.04.2018, 01:32

Не вижу в этом ничего плохого. Довольно старый приём, использующийся для рационального расхода памяти, в том числе для исключения дублирования строк в памяти скрипта
Читабельность такого становится мягко говоря затруднительной. Да и странно видеть "рациональный" расход памяти для экономия четырёх ячеек, когда рядом продублированы строки гораздо большего размера ("OnPlayerPickUpPickup"). Хотя если серьёзно, тут во всех случаях сам результат даже не стоит затрат на это.

Kovshevoy

22.04.2018, 11:47

В форке Zeex'а (http://pro-pawn.ru/showthread.php?2207-Pawn-compiler-%283-10%29) такое тоже возможно с помощью ключа -R.

С учётом всех изменений, которые произошли в форке Zeex'а за последние несколько лет (а именно на этом форке и основывается ruspawncc), проще в тот форк добавить нормальную поддержку мультиязычности. Что я и собираюсь в ближайшем будущем сделать, устное согласие от Tracker1 (ему по идее принадлежит частичное авторство над переведёнными сообщениями в ruspawncc) уже получено.
Ну, с помощью ключа оно то конечно можно, но там не особо понятно, где рекурсия и слишком много выводит сообщений.
У Вас всё коротко и просто: Обнаружена рекурсия. А мультиязычность это круто, будем ждать, спасибо.

whale

22.04.2018, 15:48

UPD v1.2.1 - Убран знак подчёркивания ("_") у префикса. Добавлен префикс для перечислений.

Daniel_Cortez

22.04.2018, 16:05

Читабельность такого становится мягко говоря затруднительной
Частично компенсируется заданием массиву такого названия, которое будет говорить о его содержимом (взять всё тот же приведённый мной выше пример: str_dd - !"dd").

Да и странно видеть "рациональный" расход памяти для экономия четырёх ячеек, когда рядом продублированы строки гораздо большего размера ("OnPlayerPickUpPickup").
Я упомянул только те строки, что заметил первыми - не было смысла выискивать и перечислять все, ибо нетрудно догадаться, что любую дублирующуюся строку в инклуде можно объявить в одном экземпляре.

Хотя если серьёзно, тут во всех случаях сам результат даже не стоит затрат на это.
Зависит от приоритетов у автора кода. Если нужно, чтобы выкладываемый в паблик код рационально расходовал ресурсы - вполне стоит того.
В любом случае, учитывая давность этого приёма, а также то, сколько людей пользовались и коммитили в те же fixes.inc, YSI и sscanf2, публичного осуждения этот приём точно не вызовет. Ну, разве что редкие недовольные возгласы отдельных пользователей, которым чуждо всё, что хоть немного усложняет код - но и то не факт.

Nexius_Tailer

22.04.2018, 19:59

Частично компенсируется заданием массиву такого названия, которое будет говорить о его содержимом (взять всё тот же приведённый мной выше пример: str_dd - !"dd").
Да даже не в названии переменной дело, а в выносе этих параметров куда-то в иное место как факт.

Зависит от приоритетов у автора кода. Если нужно, чтобы выкладываемый в паблик код рационально расходовал ресурсы - вполне стоит того.
В любом случае, учитывая давность этого приёма, а также то, сколько людей пользовались и коммитили в те же fixes.inc, YSI и sscanf2, публичного осуждения этот приём точно не вызовет. Ну, разве что редкие недовольные возгласы отдельных пользователей, которым чуждо всё, что хоть немного усложняет код - но и то не факт.
Рационально он будет расходовать и без вынесения двух или десяти символов в строку, тут скорее неоправданная погоня непонятно зачем. Ну а про то, где это юзается, тоже в общем-то ничего это не отменяет.

VVWVV

22.04.2018, 20:47

Daniel_Cortez

23.04.2018, 19:15

Ну а про то, где это юзается, тоже в общем-то ничего это не отменяет.
Зато показывает, что иногда читаемостью кода можно немного принебречь в пользу экономии в несколько десятков или сотен байт. Впрочем, это всё сугубо субъективно, равно как и твои суждения про "неоправданно" и "непонятно зачем".

Nexius_Tailer

24.04.2018, 01:13

Зато показывает, что иногда читаемостью кода можно немного принебречь в пользу экономии в несколько десятков или сотен байт. Впрочем, это всё сугубо субъективно, равно как и твои суждения про "неоправданно" и "непонятно зачем".
Говоря про память это действительно именно так и есть, потому как количество сэкономленной памяти настолько ничтожно, что это ровным счётом абсолютно ничего не изменит, не говоря уже о том, что какой-то погоды сделает. Так что тут нет ничего такого, из-за чего эту читабельность стоит ухудшать.

Daniel_Cortez

24.04.2018, 02:53

Говоря про память это действительно именно так и есть, потому как количество сэкономленной памяти настолько ничтожно, что это ровным счётом абсолютно ничего не изменит, не говоря уже о том, что какой-то погоды сделает. Так что тут нет ничего такого, из-за чего эту читабельность стоит ухудшать.
Ему говоришь о субъективности подобных суждений и отсутствии однозначно верного ответа в принципе - он продолжает гнуть свою линию, выдавая своё мнение за абсолют. Пожалуй, это реально бесполезно пытаться высказать свою точку зрения тому, у кого заткнуты уши. -_-

Nexius_Tailer

24.04.2018, 11:08

Ему говоришь о субъективности подобных суждений и отсутствии однозначно верного ответа в принципе - он продолжает гнуть свою линию, выдавая своё мнение за абсолют. Пожалуй, это реально бесполезно пытаться высказать свою точку зрения тому, у кого заткнуты уши. -_-
"Говорить" и иметь аргументированное заявление это две разные вещи, так что твой ответ не более чем твоё мнение. И раз уж речь о возведении чьего-либо мнения в абсолют, так это пока видно только от тебя.

DeimoS

26.04.2018, 12:43

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

Я ничего не хочу сказать, но твои слова так же являются лишь твоим мнением и не более того. То, что тебе в твоих скриптах не так важно экономить память, не означает, что её не важно экономить для всех.

P.S. Забавно, что именно ты так часто любишь упрекать меня в упёртости, но уже который раз даже такой упёртый я предпочитаю просто начинать тебя игнорировать, так как ты напрочь не хочешь слушать других людей, считая себя правым во всём.

Nexius_Tailer

26.04.2018, 23:53

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

P.S. Забавно, что именно ты так часто любишь упрекать меня в упёртости, но уже который раз даже такой упёртый я предпочитаю просто начинать тебя игнорировать, так как ты напрочь не хочешь слушать других людей, считая себя правым во всём.
Хз откуда ты берёшь эти сомнительные утверждения, но видимо что-то тебя сильно задевает.