Просмотр полной версии : [Вопрос] Почему не улучшается язык Pawn?
Привет.
Задался вопросом: как бы создавать мод в ООП стиле, чтоб вот прям был класс игрока, его поля и методы, а потом создавать его экземпляры и т. д., а не хранить все в массиве и в отдельных функциях.
Потом понял, что в Pawn даже сраных структур нет и это невозможно.
Почему нельзя добавить новые возможности в язык? Ведь я видел кто-то там из наших САМПовских ребят исправляет ошибки и баги компилятора. Так почему бы не добавить новый функционал? Или это как-то связано с тем, что надо согласовывать с авторами этого языка?
Потому что это не так просто сделать и этим занимается полтора человека из всего комьюнити? Или потому что те, кто сейчас держат github модифицированного компилятора, довольно редко им занимаются, а так же все идеи тщательно отфильтровываются, дабы сильно не ломать совместимость со старыми скриптами (которые, в том числе, могут работать на багах компилятора)?
Потому что это не так просто сделать и этим занимается полтора человека из всего комьюнити? Или потому что те, кто сейчас держат github модифицированного компилятора, довольно редко им занимаются, а так же все идеи тщательно отфильтровываются, дабы сильно не ломать совместимость со старыми скриптами (которые, в том числе, могут работать на багах компилятора)?
Аа, вот оно что.
Просто блуждая по форумам по Pawn, у меня создалось впечатление, что у этого языка много поклонников. Видимо, я ошибался.
Ну совместимость можно и не трогать, просто хотя бы структуры добавить или базовый функционал классов.
execution
19.05.2021, 20:10
Точно такой же вопрос можно задать разрабам C.
Наверное это неактуально для данного языка
Daniel_Cortez
19.05.2021, 20:14
Задался вопросом: как бы создавать мод в ООП стиле, чтоб вот прям был класс игрока, его поля и методы, а потом создавать его экземпляры и т. д., а не хранить все в массиве и в отдельных функциях.
Никак. В Pawn вся память резервируется статически при загрузке скрипта. Лучшее, что можно сделать - это "красть" память из сегмента стека/кучи, злоупотребляя одним из багов ВМ (стек и куча используют один сегмент памяти, с той лишь разницей, что стек "растёт" с конца сегмента, а куча - с начала; по умолчанию этот сегмент ограничен размером в 16 Кб, т.е. 4096 ячеек - при слишком большом выделении можно словить "столкновение" стека и кучи), либо сделать "имитацию" на основе глобального массива в несколько тысяч или даже миллионов ячеек, из которого и резервировать память. К слову, оба подхода уже используются в y_malloc из YSI.
Почему нельзя добавить новые возможности в язык? Ведь я видел кто-то там из наших САМПовских ребят исправляет ошибки и баги компилятора. Так почему бы не добавить новый функционал? Или это как-то связано с тем, что надо согласовывать с авторами этого языка?
Во-первых, я планирую по очереди реализовать сначала структуры, а затем и хоть какое-то подобие методов, но на их согласование и реализацию уйдёт время.
Во-вторых, сейчас в очереди и без этого достаточно изменений, которые ожидают рассмотрения и принятия. Сколько будет мариноваться очередная порция изменений - вопрос не ко мне, но последняя куча изменений копилась полгода (с середины ноября и по начало мая). Впрочем, следует понимать, что рассматривает предлагаемые в компилятор изменения всего лишь один человек, и ему же приходится тянуть на себе разработку open.mp, YSI и модифицированных инклудов SA-MP.
В-третьих, в данном контексте само по себе понятие "авторы языка" некорректно, ибо речь о неофициальном ответвлении (форке) от языка Pawn версии 3.2. И даже если в нём исправлено больше багов и добавлено больше функционала, чем в официальном Pawn 4.0, это всё равно всего лишь неофициальное ответвление, которое автором Pawn не контролируется. У форка есть лишь сопровождающие (собственно, те, кто занимается развитием форка и приёмом изменений друг от друга и от других пользователей), и из них, как я уже упомянул, активным остаётся только один человек.
Так же стоит добавить, что павн позиционирует себя как простой язык с которого можно начать свой путь в мир айти. С этой задачей он справляется прекрасно. Зачем усложнять? Хотите писать моды на С++ или Java? Используйте SDK. В чем проблема?
Что касается большого комьюнити и столь слабое развития языка. Не все знакомы с принципами работы компилятора и имеют хорошие познания в Си. При всем уважении, не наберётся и 1% таких людей от всего комьюнити.
Раз пошла такая пьянка, то все же изменения которые вносятся в компилятор на данный момент, то это диагностики. Да, они нужны, но так же нужны и другие фичи. К сожалению из-за основного направления я не могу найти время разобраться в коде компилятора. Но есть как минимум две просьбы к @Daniel_Cortez:
Пофиксить тот баг с файлами (когда кодировка не совпадает в препроцессорах (https://github.com/pawn-lang/compiler/issues/181)) и/или добавить диагностику на счет этого.
Добавить больше измерений в массивах.
Добавить прогрессивную иницилизацию для многомерных массивов (я уже как-то писал и там были "лайки". так что это нужна фича коммьюнити (https://pro-pawn.ru/showthread.php?2207-Pawn-compiler-%283-10%29&p=97624&viewfull=1#post97624))
P.S: Я понимаю что ты убиваешь собственное время и в приоритете свои фичи, но думаю что иногда можно прислушаться с коммьюнити :)
Никак. В Pawn вся память резервируется статически при загрузке скрипта. Лучшее, что можно сделать - это "красть" память из сегмента стека/кучи, злоупотребляя одним из багов ВМ (стек и куча используют один сегмент памяти, с той лишь разницей, что стек "растёт" с конца сегмента, а куча - с начала; по умолчанию этот сегмент ограничен размером в 16 Кб, т.е. 4096 ячеек - при слишком большом выделении можно словить "столкновение" стека и кучи), либо сделать "имитацию" на основе глобального массива в несколько тысяч или даже миллионов ячеек, из которого и резервировать память. К слову, оба подхода уже используются в y_malloc из YSI.
Во-первых, я планирую по очереди реализовать сначала структуры, а затем и хоть какое-то подобие методов, но на их согласование и реализацию уйдёт время.
Во-вторых, сейчас в очереди и без этого достаточно изменений, которые ожидают рассмотрения и принятия. Сколько будет мариноваться очередная порция изменений - вопрос не ко мне, но последняя куча изменений копилась полгода (с середины ноября и по начало мая). Впрочем, следует понимать, что рассматривает предлагаемые в компилятор изменения всего лишь один человек, и ему же приходится тянуть на себе разработку open.mp, YSI и модифицированных инклудов SA-MP.
В-третьих, в данном контексте само по себе понятие "авторы языка" некорректно, ибо речь о неофициальном ответвлении (форке) от языка Pawn версии 3.2. И даже если в нём исправлено больше багов и добавлено больше функционала, чем в официальном Pawn 4.0, это всё равно всего лишь неофициальное ответвление, которое автором Pawn не контролируется. У форка есть лишь сопровождающие (собственно, те, кто занимается развитием форка и приёмом изменений друг от друга и от других пользователей), и из них, как я уже упомянул, активным остаётся только один человек.
Круто, буду ждать с нетерпением!
Daniel_Cortez
21.05.2021, 21:17
Раз пошла такая пьянка, то все же изменения которые вносятся в компилятор на данный момент, то это диагностики. Да, они нужны, но так же нужны и другие фичи.
Не только диагностики. Из самого значимого, что будет в следующем релизе:
switch-выражения (https://github.com/pawn-lang/compiler/pull/640) (PR ещё не принят, но согласован с Y_Less'ом и финализирован, ожидает следующего рассмотрения);
операторы __static_assert и __static_check (https://github.com/pawn-lang/compiler/pull/614);
оператор __pragma (https://github.com/pawn-lang/compiler/pull/526) (аналог директивы #pragma, который можно использовать в макросах);
Однако, я намеренно не добавляю этот функционал в свои "неофициальные" релизы, чтобы избежать случаев, когда пользователи преждевременно подстраивают свои скрипты к новым возможностям компилятора.
Например, если нужно использовать в макросе новый функционал __pragma, но при этом сохранить совместимость со старыми версиями компилятора, то в следующей версии (3.10.11) это можно будет сделать так:
#if __Pawn >= 0x030A && defined __PawnBuild
#if __PawnBuild >= 11
#define _MAYBE_UNUSED_ __pragma("unused")
#endif
#endif
#if !defined _MAYBE_UNUSED_
#define _MAYBE_UNUSED_
#endif
// ...
new _MAYBE_UNUSED_ x; // компилятор не будет жаловаться, что переменная не используется
Однако мои билды распознаются как текущая версия (3.10.10), поэтому если я добавлю туда что-то из нового функционала, пользователи начнут адаптировать под него скрипты так, как будто он появился в текущей версии, а не в следующей:
#if __Pawn >= 0x030A && defined __PawnBuild
#if __PawnBuild >= 10
#define _MAYBE_UNUSED_ __pragma("unused")
#endif
#endif
Такая фрагментация среди сообщества недопустима и я не хотел бы вносить в неё вклад. Именно поэтому я специально не включаю новый функционал в свои билды, а добавляю только самое необходимое: багфиксы и новые диагностики.
В принципе про диагностики тоже можно заявить, что они нарушают совместимость, но на самом деле с ними всё проще: для их отключения не обязательно полагаться на конкретную версию компилятора, достаточно лишь проверить объявление __PawnBuild (появилось в релизе 3.10.1, вышедшем 4 года назад), чтобы убедиться, что это не слишком старая версия компилятора и мы можем использовать #pragma warning:
#if __Pawn >= 0x30A && defined __PawnBuild
#pragma warning disable 249
#endif
Если в компиляторе есть 249-я диагностика, она будет отключена, если нет - строка с #pragma будет проигнорирована.
Пофиксить тот баг с файлами (когда кодировка не совпадает в препроцессорах (https://github.com/pawn-lang/compiler/issues/181)) и/или добавить диагностику на счет этого.
По-моему, я уже как-то говорил на этом форуме, что это не просто баг, а недоработка в коде чтения/препроцессирования исходных файлов. Изменения в столь фундаментальном механизме могут отразиться на совместимости с некоторыми скриптами/инклудами, или же замедлить компиляцию.
Добавить больше измерений в массивах.
Уже поддерживается до четырёх измерений. Если есть какие-то реалистичные примеры, в которых может понадобиться 5 или более измерений - я готов выслушать их и при необходимости запросить у сопровождающих компилятора, чтобы увеличили лимит.
Добавить прогрессивную иницилизацию для многомерных массивов (я уже как-то писал и там были "лайки". так что это нужна фича коммьюнити (https://pro-pawn.ru/showthread.php?2207-Pawn-compiler-%283-10%29&p=97624&viewfull=1#post97624))
Тоже уже говорил об этом раньше, что в последний раз, когда смотрел на код инициализации массивов, ничего из этого спагетти толком разобрать не смог.
P.S: Я понимаю что ты убиваешь собственное время и в приоритете свои фичи, но думаю что иногда можно прислушаться с коммьюнити :)
Проблемы, перечисленные выше, я оставляю на потом не из вредности. То, что я исправляю баги и делаю какие-то новые фичи для компилятора, не значит, что я всемогущий. Бывают проблемы, в правильном решении которых я не уверен, или какие-то вещи, в которых не разбираюсь - к таким вещам я привык возвращаться позже, когда лучше разберусь в вопросе, дабы не терять время на бесполезные поиски решения, а с гораздо большей эффективностью потратить его на устранение других проблем.
По-моему, я уже как-то говорил на этом форуме, что это не просто баг, а недоработка в коде чтения/препроцессирования исходных файлов. Изменения в столь фундаментальном механизме могут отразиться на совместимости с некоторыми скриптами/инклудами, или же замедлить компиляцию.
Ок. Банальная диагностика и ошибка (?), чтобы люди не тратили много времени, которые не знают об этом.
Уже поддерживается до четырёх измерений. Если есть какие-то реалистичные примеры, в которых может понадобиться 5 или более измерений - я готов выслушать их и при необходимости запросить у сопровождающих компилятора, чтобы увеличили лимит.
Из последних моих систем, которые требовали бы больше измерений то это казино. Если нужно, то могу более подробней рассказать, но это не первый случай, когда не хватает 4 измерении. Чем чревато добавления ключа в компилятор (если такое вообще возможно, не знаю внутренних механизмов массивов), чтобы можно было отрегулировать максимальное значение измерений в массивах? Можно сделать запрет, допустим до 6. Я думаю, что 6 уже будет достаточно. Ибо лучше тратить память, чем процессорное время :)
UPD: Ага, оно просто задано константой (https://github.com/pawn-lang/compiler/blob/134ad7a836c581546665340aedb59efd4636e269/source/compiler/sc.h#L72). Тогда оптимальный вариант, добавить ключ в компилятор, допустим -adim count. (соответственно, сделать ограничение в этом ключе до 6 допустим или в рамках разумного. По умолчанию оставить: 4) Кому не нужно, тот не платит за повышение количество измерений, а кому нужно, тот может поднять.
А как тогда избавиться от повторяющегося кода?
Сейчас работаю над системой инвентарей и пока пишу код думаю "блин, я же буду писать тоже самое для системы шкафа/багажника/склада и т. д.", т. к. они все будут однотипны: у них есть окно, слоты, айтемы внутри, меню для взаимодействия с айтемом.
Соответственно, можно было бы написать какой-нибудь базовый класс Container с методами addItem, removeItem и со свойствами например weight, capacity и т. д. И от него наследовались бы Inventory, Trunk, Storage и т. п.
Но гавн вынуждает меня создавать однотипные функции и enum'ы.
Не только диагностики. Из самого значимого, что будет в следующем релизе:
switch-выражения (https://github.com/pawn-lang/compiler/pull/640) (PR ещё не принят, но согласован с Y_Less'ом и финализирован, ожидает следующего рассмотрения);
операторы __static_assert и __static_check (https://github.com/pawn-lang/compiler/pull/614);
оператор __pragma (https://github.com/pawn-lang/compiler/pull/526) (аналог директивы #pragma, который можно использовать в макросах);
Однако, я намеренно не добавляю этот функционал в свои "неофициальные" релизы, чтобы избежать случаев, когда пользователи преждевременно подстраивают свои скрипты к новым возможностям компилятора.
Например, если нужно использовать в макросе новый функционал __pragma, но при этом сохранить совместимость со старыми версиями компилятора, то в следующей версии (3.10.11) это можно будет сделать так:
#if __Pawn >= 0x030A && defined __PawnBuild
#if __PawnBuild >= 11
#define _MAYBE_UNUSED_ __pragma("unused")
#endif
#endif
#if !defined _MAYBE_UNUSED_
#define _MAYBE_UNUSED_
#endif
// ...
new _MAYBE_UNUSED_ x; // компилятор не будет жаловаться, что переменная не используется
Однако мои билды распознаются как текущая версия (3.10.10), поэтому если я добавлю туда что-то из нового функционала, пользователи начнут адаптировать под него скрипты так, как будто он появился в текущей версии, а не в следующей:
#if __Pawn >= 0x030A && defined __PawnBuild
#if __PawnBuild >= 10
#define _MAYBE_UNUSED_ __pragma("unused")
#endif
#endif
Такая фрагментация среди сообщества недопустима и я не хотел бы вносить в неё вклад. Именно поэтому я специально не включаю новый функционал в свои билды, а добавляю только самое необходимое: багфиксы и новые диагностики.
В принципе про диагностики тоже можно заявить, что они нарушают совместимость, но на самом деле с ними всё проще: для их отключения не обязательно полагаться на конкретную версию компилятора, достаточно лишь проверить объявление __PawnBuild (появилось в релизе 3.10.1, вышедшем 4 года назад), чтобы убедиться, что это не слишком старая версия компилятора и мы можем использовать #pragma warning:
#if __Pawn >= 0x30A && defined __PawnBuild
#pragma warning disable 249
#endif
Если в компиляторе есть 249-я диагностика, она будет отключена, если нет - строка с #pragma будет проигнорирована.
По-моему, я уже как-то говорил на этом форуме, что это не просто баг, а недоработка в коде чтения/препроцессирования исходных файлов. Изменения в столь фундаментальном механизме могут отразиться на совместимости с некоторыми скриптами/инклудами, или же замедлить компиляцию.
Уже поддерживается до четырёх измерений. Если есть какие-то реалистичные примеры, в которых может понадобиться 5 или более измерений - я готов выслушать их и при необходимости запросить у сопровождающих компилятора, чтобы увеличили лимит.
Тоже уже говорил об этом раньше, что в последний раз, когда смотрел на код инициализации массивов, ничего из этого спагетти толком разобрать не смог.
Проблемы, перечисленные выше, я оставляю на потом не из вредности. То, что я исправляю баги и делаю какие-то новые фичи для компилятора, не значит, что я всемогущий. Бывают проблемы, в правильном решении которых я не уверен, или какие-то вещи, в которых не разбираюсь - к таким вещам я привык возвращаться позже, когда лучше разберусь в вопросе, дабы не терять время на бесполезные поиски решения, а с гораздо большей эффективностью потратить его на устранение других проблем.
А почему не используется компилятор 4-й версии? Это проблемно перейти на него?
Хотел использовать такую вот штуку
https://i.ibb.co/k8F8Nnk/2.png
Но разочаровался( Не робит
Эмм, если ты, при виде Pawn, так удивляешься тому, что не все языки - это C/C++, то что же с тобой будет когда ты до какого-нибудь Lua/Python доберёшься или вообще какой-нибудь Brainfuck увидишь? Да, Pawn не так гибок в функционале, но странно этой гибкости ждать от языка, основная задача которого - облегчить жизнь новичкам в программировании, дабы те не страдали от проблем при работе с памятью. Впрочем. не суть.
А как тогда избавиться от повторяющегося кода?
Никак. Тебе в любом случае придётся явно прописывать, как минимум, часть кода для новых систем. А функции, при желании, можно сделать универсальными. Правда, ты этим только усложнишь последующую поддержку кода, но если очень хочется - дерзай.
Сейчас работаю над системой инвентарей и пока пишу код думаю "блин, я же буду писать тоже самое для системы шкафа/багажника/склада и т. д.", т. к. они все будут однотипны: у них есть окно, слоты, айтемы внутри, меню для взаимодействия с айтемом.
Соответственно, можно было бы написать какой-нибудь базовый класс Container с методами addItem, removeItem и со свойствами например weight, capacity и т. д. И от него наследовались бы Inventory, Trunk, Storage и т. п.
Но гавн вынуждает меня создавать однотипные функции и enum'ы.
Тебе никто не запрещает написать мод в виде плагина, использовав так любимый тобой C++ или что тебе там нравится. Правда, сомневаюсь, что от этого твоя эффективность повысится, но, в любом случае, такая возможность у тебя есть.
А почему не используется компилятор 4-й версии? Это проблемно перейти на него?
Хотел использовать такую вот штуку
https://i.ibb.co/k8F8Nnk/2.png
Но разочаровался( Не робит
https://pro-pawn.ru/showthread.php?14174
Эмм, если ты, при виде Pawn, так удивляешься тому, что не все языки - это C/C++, то что же с тобой будет когда ты до какого-нибудь Lua/Python доберёшься или вообще какой-нибудь Brainfuck увидишь? Да, Pawn не так гибок в функционале, но странно этой гибкости ждать от языка, основная задача которого - облегчить жизнь новичкам в программировании, дабы те не страдали от проблем при работе с памятью. Впрочем. не суть.
А что не так с Python? Думаю, на нем бы мод писался лучше.
Python тоже зарекомендовал себя как язык для новичков и в этом плане даже лучше гавна, тоже нет никакой работы с памятью.
Просто я хотел красиво оформить исходники мода, а не писать новую функцию только потому, что она обращается к массиву с другим именем. На гавне приходится мириться с многими недостатками, что убивает у меня удовольствие от написания мода.
Никак. Тебе в любом случае придётся явно прописывать, как минимум, часть кода для новых систем. А функции, при желании, можно сделать универсальными. Правда, ты этим только усложнишь последующую поддержку кода, но если очень хочется - дерзай.
Да, я думал создать универсальные функции, но это не очень. Ну может, подумаю над этим еще.
Тебе никто не запрещает написать мод в виде плагина, использовав так любимый тобой C++ или что тебе там нравится. Правда, сомневаюсь, что от этого твоя эффективность повысится, но, в любом случае, такая возможность у тебя есть.
Как это делается? sampgdk как раз для этого? Или я путаю?
https://pro-pawn.ru/showthread.php?14174
О, спасибо, надо попробовать.
UPD: Проект мертв(
Ну и вопросик еще один. В том же С++, например, когда ООП код с наследованием компилируется в output - в нем наследуемые методы (функции) также в единственном экземпляре существуют как в прописано в исходном файле?
А что не так с Python? Думаю, на нем бы мод писался лучше.
Python тоже зарекомендовал себя как язык для новичков и в этом плане даже лучше гавна, тоже нет никакой работы с памятью.
С Python всё так. Просто это ещё один язык, который отличается от того же С++ и не повторяет его возможностей.
Повторюсь, у каждого языка есть свои сильные и слабые стороны. А ты сейчас пытаешься натянуть какие-то свои предпочтения на язык, задачи которого заключаются совершенно в другом, да ещё и так кринжово зачем-то название коверкаешь. И особенно кринжово всё это выглядит с учётом того, что для SAMP есть плагины-интерпритаторы для многих языков: тот же SAMPHP, например. Да и, при большом желании, можно даже самому реализовать нечто подобное. Но ты, видимо, предпочитаешь просто критиковать язык и, при этом, продолжать им пользоваться, что странно. Как говорится: "мыши плакали, кололись, но продолжали жрать кактус" =)
Просто я хотел красиво оформить исходники мода, а не писать новую функцию только потому, что она обращается к массиву с другим именем. На гавне приходится мириться с многими недостатками, что убивает у меня удовольствие от написания мода.
Твоя проблема в том, что ты воспринимаешь язык не как инструмент. Вместо того, чтоб понять особенность языка и просто начать её использовать, ты зачем-то начинаешь сравнивать один язык с другим - в чём нет совершенно никакого смысла. Нужно уметь переключаться с одного языка на другой. Просто хотя бы для того, чтоб самому себе нервы лишний раз не портить.
Собственно, "проблема" с отсутствием ООП решается делением мода на файлы и правильным структурированием кода в них. Да, это, возможно, не избавит от частичного дублирования кода, но всё же сделает его опрятным и удобным в последующем поддержании.
Как это делается? sampgdk как раз для этого? Или я путаю?
Да хоть sampgdk, хоть собственную библиотеку реализуй. Было бы желание.
На эту тему и статьи видел, и даже мод готовый кто-то в паблик сливал.
Daniel_Cortez
30.05.2021, 18:15
Ок. Банальная диагностика и ошибка (?), чтобы люди не тратили много времени, которые не знают об этом.
Даже если и реализовать такую ошибку, компилятор банально не успеет вывести её перед крашем. Проблема в том, что падение происходит на этапе препроцессирования, когда варнинги и сообщения об ошибках отключены (так сделано специально, т.к. изначально возникает много ложных ошибок и предупреждений, которые разрешаются только при последнем проходе компилятора).
Из последних моих систем, которые требовали бы больше измерений то это казино. Если нужно, то могу более подробней рассказать, но это не первый случай, когда не хватает 4 измерении.
Если это и в самом деле очень нужно, то да, лучше расскажи. Просить об этом сопровождающих компилятора от своего имени я не хотел бы, но если есть свой аккаунт на GitHub - готов помочь с переводом/подготовкой обращения. Самое главное - это показать сопровождающим реальный пример, где нужно более 4 измерений в массивах.
А почему не используется компилятор 4-й версии? Это проблемно перейти на него?
На момент внедрения в SA-MP, последней версией языка была 3.2. В 4.0 сильно изменился синтаксис, сломана совместимость со скриптами для 3-й версии. Мало кто захочет переписывать свои скрипты под новый язык.
Python тоже зарекомендовал себя как язык для новичков
Учить новичков на языке с нулевым контролем над ошибками? Отличная идея!
UPD: Тем временем, удалось согласовать первый этап по внедрению подобия ООП в виде методов, привязанных к тегам:
https://github.com/pawn-lang/compiler/issues/234#issuecomment-850971040
На следующей неделе, как будет время, попробую поэкспериментировать с реализацией.
UPD: Тем временем, удалось согласовать первый этап по внедрению подобия ООП в виде методов, привязанных к тегам:
https://github.com/pawn-lang/compiler/issues/234#issuecomment-850971040
На следующей неделе, как будет время, попробую поэкспериментировать с реализацией.
Интересный синтаксис:
native Tag_Function(Tag:this, a, b);
stock Tag_Function(Tag:this, a, b)
{
}
Если я правильно понял, то this, "указатель/ссылка" на класс в чей области находится метод? С чем связанно такое решение? В других языках this на свой же класс передается не явно и мне кажется это best practice.
Daniel_Cortez
31.05.2021, 19:05
Если я правильно понял, то this, "указатель/ссылка" на класс в чей области находится метод?
В других языках this на свой же класс передается не явно и мне кажется это best practice.
Не совсем правильно. По сути Y_Less предлагал что-то вроде автозамены "Tag.Function(a, b)" на "Tag_Function(Tag:this, a, b)", как в макросах, объясняя это простотой реализации. В посте по ссылке выше я раскритиковал такую идею, ибо лепить "Tag.Function" в одно имя "Tag_Function" - заведомо провальная идея из-за лимита в 31 символ.
Касаемо конкретно this, по задумке этот аргумент должен указываться неявно, и в этом плане у меня претензий нет.
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot