ООП в МТА 1.4

Всем привет!

Как известно, в МТА 1.4 представлена поддержка ООП. Прочитав OOP Introduction я понял что вся стандартная система функций была переделана под ООП синтаксис, добавлены новые фичи и т.д., но не понятно как подразумевается это нужно использовать. Сам я раньше ООП в луа не юзал, поэтому хочу понять как теперь написание скриптов видят разработчики МТА, которые делали это обновление. Должен ли я скриптить используя старые функции по новому, при этом продолжать писать как на процедурном языке (но это ведь каша какая-то)? Или я должен начать юзать "ООП" в луа (но каким тогда образом? Ведь как я понял нативных механизмов создания кастомных классов никто туда не добавлял, выходит я должен сам включать их в каждый ресурс)? Просветите кто в курсе

Создание своих классов не предусмотрено. То что сделали в МТА очень сложно назвать "ООП". То что вызов происходит через точку\двоеточие не значит, что это ООП.

Всё что и добавили в МТА - это всего лишь регистры для Lua позволяющие обращаться к userdata как к таблицам, т.е. вызов методов и доступ к членам. Больше ничего.

В ООП как минимум должно быть Наследование, Полиморфизм хотя бы. В идеале конечно бы и Инкапсуляция ещё.

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

Вы с метатаблицами уже разобрались? Если нет то почитайте [Lua] setmetatable, учимся работать с метатаблицами и [Lua] Магия с типами или debug.setmetatable.

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

Спасибо за ответы.

Вы с метатаблицами уже разобрались? Если нет то почитайте [Lua] setmetatable, учимся работать с метатаблицами и [Lua] Магия с типами или debug.setmetatable.

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

Создание своих классов не предусмотрено. То что сделали в МТА очень сложно назвать "ООП". То что вызов происходит через точку\двоеточие не значит, что это ООП.

Всё что и добавили в МТА - это всего лишь регистры для Lua позволяющие обращаться к userdata как к таблицам, т.е. вызов методов и доступ к членам. Больше ничего.

В ООП как минимум должно быть Наследование, Полиморфизм хотя бы. В идеале конечно бы и Инкапсуляция ещё.

Прикольно ты длинными словами кидаешься, но вот те поворот:

- наследственность присутствует, отражая внутреннюю структуру классов. Player наследует методы/свойства от Ped, а тот в свою очередь от Element. Например метод setData определен только в классе Element, но player:setData вполне себе работает, и можно даже переопределить исключительно для объектов класса Player.

- полиморфизм тоже присутствует, все как и раньше, vehicle:setParent ( object ) - чем не полиморфизм?

Для общего развития, на моей странице в вики есть структура мета таблиц: тык. И для особо продвинутых есть возможность эти мета таблицы переопределить по своему вкусу.

Инкапсуляция? Извините, если МТА добавит приватные методы в Lua классы, кто же, блин, будет их вызывать?!?! Где смысл? В своих - сколько влезит, каркас есть.

OOP дает скриптерам больше чем это, стандартные имплементации векторов/матриц и т.д. будут делать математику за вас. Очень популярная тема: как взять точку перед игроком? В ООП очень просто: player.matrix.forward, можно даже на определенном расстоянии: player.matrix.forward * length. И планов по развитию еще море.

Если есть какие-то свои предложения, добро пожаловать на баг трекер или в ирк. А раз все молчат - подразумеваем предложений нет, или каждому надо лично написать и спросить? Уж пора бы запомнить.

Прикольно ты длинными словами кидаешься, но вот те поворот:

- наследственность присутствует, отражая внутреннюю структуру классов. Player наследует методы/свойства от Ped, а тот в свою очередь от Element. Например метод setData определен только в классе Element, но player:setData вполне себе работает, и можно даже переопределить исключительно для объектов класса Player.

- полиморфизм тоже присутствует, все как и раньше, vehicle:setParent ( object ) - чем не полиморфизм?

Для общего развития, на моей странице в вики есть структура мета таблиц: тык. И для особо продвинутых есть возможность эти мета таблицы переопределить по своему вкусу.

Инкапсуляция? Извините, если МТА добавит приватные методы в Lua классы, кто же, блин, будет их вызывать?!?! Где смысл? В своих - сколько влезит, каркас есть.

OOP дает скриптерам больше чем это, стандартные имплементации векторов/матриц и т.д. будут делать математику за вас. Очень популярная тема: как взять точку перед игроком? В ООП очень просто: player.matrix.forward, можно даже на определенном расстоянии: player.matrix.forward * length. И планов по развитию еще море.

Ты видимо вобще не понимаешь о чём речь. Попробую объяснить.

То о чём ты сейчас сказал - это всё касается лишь C++, т.е. то на чём это всё реализовано. Конечно вы это реализовали всё красиво со всеми принципами ООП, как положено - да не спорю, вам удобно, вам хорошо. А что на выходе имеем мы? Только лишь доступ к членам (и то чтобы добавить свои - надо ковырять регистры Lua).

Как изменился код? Вместо setElementHealth( Player, 70.0 ) стало просто Player:setHealth( 70.0 ), либо Player.Health = 70.0. По сути ничего не изменилось, как было императивное программирование так и осталось.

Говоря о Наследовании, Полиморфизме и Инкапсуляции - имелось ввиду в самой Lua. ООП должно быть у нас внутри. А то что вы реализовали ООП на уровне ООП у себя - не говорит ничего. У вас весь МТА на ООП - и что?

Реализация игровых режимов так и осталась на старом уровне.

Посмотри на ту же реализацию Windows Forms и сравни с тем что мы имеем в МТА.

В идеале я себе представлял что-то вроде этого:

  
// Resource.lua 
  
class: Resource ( LuaBehaviour ) 
{ 
    Game        = false; 
     
    OnStart     = function() 
        // По сути тот же самый OnResourceStart 
        // Так же сюда невидимым образом передаётся this (как в случае с source, client и т.п.) 
         
        this.Game = Game(); 
    end; 
     
    OnStop      = function() 
        // OnResourceStop 
         
        this.Game = NULL; // А тут должен сработать сборщик мусора и вызвать деструктор, если определён. 
    end; 
}; 
  
// Game.lua 
  
class: Game 
{ 
    Game    = function() 
        // Конструктор 
        // в котором мы уже делаем свои штуки: обращение к БД, создание машин и прочего. 
        // лучше конечно реализовывать отдельными классами. 
    end; 
     
    _Game   = function() 
        // Деструктор 
        // а тут мы сохраняем данные игроков, машин, %вставьте своё% в БД 
    end; 
}; 
  

LuaBehaviour - это такой класс который имеет в себе всё необходимое. Из него происходят вызовы всех этих OnRender (OnClientRender) и т.д.

С элементами должно быть точно так же, должен быть подобный класс, например VehicleGameType на базе которого будет строиться класс Vehicle уже самим пользователем. Ну и конечно учитывая данную ситуацию, класс Vehicle уже по умолчанию должен быть создан, иначе старые скрипты на "ООП" не будут работать.

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

Если есть какие-то свои предложения, добро пожаловать на баг трекер или в ирк. А раз все молчат - подразумеваем предложений нет, или каждому надо лично написать и спросить? Уж пора бы запомнить.

Ты сам-то понимаешь, что 99% русских скриптеров в МТА не могут и пару слов связать на английском языке?

Поэтому все предложения находятся на этом форуме.

Я сам к примеру затрудняюсь порой общаться в IRC с кем либо, единственное с кем более менее получается - это с ccw и jhxp, с остальными не получилось наладить контакт. ccw за ООП не отвечает, и на сколько я помню отвечаешь за него - ты сам. Но тебя самого в IRC трудно поймать.

Еще вопрос. Пытаюсь использовать одну библиотеку, реализующую ооп. В коде что ниже: класс SpecialVehicle - наследник класса Vehicle.

Vehicle = class( "Vehicle",  
{ 
    vehicleElement; 
     
    __init = function( self, model, x, y, z ) 
        self.vehicleElement = createVehicle( model, x, y, z ) 
    end; 
} ) 
  
SpecialVehicle = class( "SpecialVehicle", Vehicle,  
{ 
    blow = function( self ) 
        blowVehicle( self.vehicleElement ) 
    end; 
} ) 
  
addCommandHandler( "spveh", 
    function( cmd, model ) 
        local x, y, z = getElementPosition( localPlayer ) 
        myVehicle = SpecialVehicle( model, x+2, y, z ) 
    end 
) 
  
addCommandHandler( "blowveh", 
    function() 
        myVehicle:blow() 
    end 
) 

На строке 13 выдает ошибку, якобы self.vehicleElement = nil. Я так понял это из-за того, что при наследовании, в SpecialVehicle передаются все данные класса Vehicle, но передаются единожды, и vehicleElement хоть и передался со значением, которое у него на тот момент было, является уже другим vehicleElement, принадлежащим только SpecialVehicle, следовательно когда срабатывает конструктор, меняется только значение в классе Vehicle, а метод blow пытается использовать старое, ранее полученное значение (nil).

А вопрос в том, недостаток ли это "библиотеки", или в целом в луашном ооп не сделать норм?

Во-первых, лучше сразу говорить какая библиотека. Полноценность реализации ООП, только от неё зависит.

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

Ты видимо вобще не понимаешь о чём речь. Попробую объяснить.

То о чём ты сейчас сказал - это всё касается лишь C++, т.е. то на чём это всё реализовано. Конечно вы это реализовали всё красиво со всеми принципами ООП, как положено - да не спорю, вам удобно, вам хорошо. А что на выходе имеем мы? Только лишь доступ к членам (и то чтобы добавить свои - надо ковырять регистры Lua).

Как изменился код? Вместо setElementHealth( Player, 70.0 ) стало просто Player:setHealth( 70.0 ), либо Player.Health = 70.0. По сути ничего не изменилось, как было императивное программирование так и осталось.

Говоря о Наследовании, Полиморфизме и Инкапсуляции - имелось ввиду в самой Lua. ООП должно быть у нас внутри. А то что вы реализовали ООП на уровне ООП у себя - не говорит ничего. У вас весь МТА на ООП - и что?

Реализация игровых режимов так и осталась на старом уровне.

Эммм, никого не хочу задеть, но это довольно странный ответ.

На предыдущий пост, в котором было сказано, что мол не хватает полиморфизма и наследственности, было отвечено, что это не так. И Lil Toady прав, они есть. И используются очень многими, мной тоже. Если нужны примеры использования, могу привести отдельно.

Lua всего лишь имитирует ООП, возможно по другими принципам ООП и есть вопросы, но как раз упомянутые наследственность и полиморфизм работают. И их можно и нужно использовать.

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

Эта возможность у нас есть

Во-первых, лучше сразу говорить какая библиотека. Полноценность реализации ООП, только от неё зависит.

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

Библиотеку взял отсюда: http://mydc.ru/topic1429.html

Насчет отладки, я же и проверил, сделав изначально vehicleElement = 0 в классе Vehicle. В дебаге стало писать что вместо машины получен 0, при использовании метода blow. Из этого и сделал вывод что значение то наследуется, но потом уже не изменяется в классе-наследнике.

Эта возможность у нас есть

Правда? И как мне стандартными способами создать класс, с конструктором и кастомными методами, а потом создать несколько объектов этого класса к примеру?

Ты видимо вобще не понимаешь о чём речь. Попробую объяснить.

То о чём ты сейчас сказал - это всё касается лишь C++, т.е. то на чём это всё реализовано. Конечно вы это реализовали всё красиво со всеми принципами ООП, как положено - да не спорю, вам удобно, вам хорошо. А что на выходе имеем мы? Только лишь доступ к членам (и то чтобы добавить свои - надо ковырять регистры Lua).

Как изменился код? Вместо setElementHealth( Player, 70.0 ) стало просто Player:setHealth( 70.0 ), либо Player.Health = 70.0. По сути ничего не изменилось, как было императивное программирование так и осталось.

Говоря о Наследовании, Полиморфизме и Инкапсуляции - имелось ввиду в самой Lua. ООП должно быть у нас внутри. А то что вы реализовали ООП на уровне ООП у себя - не говорит ничего. У вас весь МТА на ООП - и что?

Реализация игровых режимов так и осталась на старом уровне.

Эммм, никого не хочу задеть, но это довольно странный ответ.

На предыдущий пост, в котором было сказано, что мол не хватает полиморфизма и наследственности, было отвечено, что это не так. И Lil Toady прав, они есть. И используются очень многими, мной тоже. Если нужны примеры использования, могу привести отдельно.

Lua всего лишь имитирует ООП, возможно по другими принципам ООП и есть вопросы, но как раз упомянутые наследственность и полиморфизм работают. И их можно и нужно использовать.

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

Эта возможность у нас есть

Давай примеры. Я выше привёл свои, как это должно работать.

Естественно без помощи сторонних библиотек, всё должно быть на уровне самой MTA.

Давай примеры. Я выше привёл свои, как это должно работать.

Естественно без помощи сторонних библиотек, всё должно быть на уровне самой MTA.

Я не знаю что такое уровень MTA в этом деле. У меня используется ООП, имитируемый языком Lua.

Мой пример не из МТА, тем более Lil Toady уже привел примеры из него.

Приведу теоретический пример из собственного проекта: реализация логики транспортных средств (vehicles).

Для наглядности картинка с фрагментом структуры моего проекта:

Наследственность

Как вы наверняка догадались, все производные классы с более сложными названиями наследуются из корневого класса из файла vehicle.lua

Класс из vehicle.lua содержит основные методы и обработчики событий (будем называть их просто одним словом "функции"). Например, при респавне (onVehicleRespawn) я должен у всех видов vehicle производить одинаковые действия: выключить фары (setVehicleOverrideLights), выключить двигатель (setVehicleEngineState) и прочее. Следуя принципу наследования я реализовал это в родительском классе из vehicle.lua и это выполняется для всех.

Далее, как можно видеть из названий файлов, содержащих классы "детей", есть некоторые специальные виды транспорта с чисто своими функциями. Например, при попытке повреждения "policevehicle" (как и "fbivehicle" или "nationalguardvehicle") игроку (если он не полицейский, не из ФБР и тд...) выдаются звезды розыска.

Или, например, "ownvehicle" имеет собственный метод lock --> закрыть транспортное средство.

Полиморфизм

Кроме функций общего характера, класс из vehicle.lua содержит пустые функции, которые переопределяются в некоторых (или некотором) из его "детей". Например, метод save --> сохранить данные автомобиля.

Этот метод вызывается при каждом изменении данных автомобилей (например, изменения цвета в покрасках). Но он пуст в vehicle.lua, то есть для всех видов автомобилей и переопределен только в классе из ownvehicle.lua. Потому что только собственные автомобили (у меня – купленные в автосалоне) должны сохраняться. И вместо того, чтобы устраивать проверки какой перед нами автомобиль, мы не глядя вызываем метод save, а код сам разберется сохранять или нет.

Ну и задача доступа к тому или иному виду транспорта легко и непринужденно решается с помощью полиморфизма.

Это далеко не единственные примеры применения этих двух принципов, но я выбрал самые наглядные.

Это вполне себе годная имитация ООП, которая реально облегчает жизнь. Другое дело, что если пытаться использовать ООП, не зная зачем и что это даст, в этом случае, я думаю, жизнь скорее осложнится.

Таким образом, наследственность и полиморфизм есть и их можно использовать.

Ты не показал конкретного примера. Я хочу видеть код, хочу видеть как выглядят твои "Наследственность" и Полиморфизм.

И как я говорил выше - без каких либо библиотек. Ибо я и до введения ООП в МТА использовал и продолжаю использовать собственные библиотеки для реализации классов подобно C# (пример). Но я хочу видеть нативные функции для реализации всего этого, собственно о чём и шла речь с самого начала.

Например LuaBind даёт такой функционал, можно объявлять собственные классы в таком виде:

class "Vehicle" ( Element ); 

И заметь, все созданные объекты являются userdata, а не table. Это уже как минимум даёт возможность повесить событие __gc и использовать для вызова деструктора.

Конечно можно опять же таки своими библиотеками реализовать создание классов на базе элементов. Но какой тогда смысл введённого ООП в MTA? Смысл в том чтобы тоже самое работало быстрее и не приходилось бы костылять библиотеки для каждого ресурса.

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

Поэтому МТА нужно ввести ключевое слово "class" для объявления собственных классов, с возможность наследования, вызов кострукта\деструктора и определения свойств с методами get и set.

Ты не показал конкретного примера. Я хочу видеть код, хочу видеть как выглядят твои "Наследственность" и Полиморфизм.

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

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

И как я говорил выше - без каких либо библиотек. Ибо я и до введения ООП в МТА использовал и продолжаю использовать собственные библиотеки для реализации классов подобно C# (пример). Но я хочу видеть нативные функции для реализации всего этого, собственно о чём и шла речь с самого начала.

Например LuaBind даёт такой функционал, можно объявлять собственные классы в таком виде:

class "Vehicle" ( Element ); 

По поводу библиотек. Я не использую библиотеки, для меня они слишком универсальны. И подозреваю, что их значение у тебя переоценено. Если ты думаешь, что какие-то библиотеки создают классы каким-то своим магическим образом, недоступным для тебя, ты ошибаешься. Они точно также имитируют создание классов, которых в Lua на самом деле нет.

Все остальное я не совсем понял. Все созданные объекты являются "userdata" - всмысле в МТА, тогда да. А если ты имеешь в виду экземпляры класса в коде - то не факт. У меня объекты класса - это тоже таблицы, одна из ячеек которой содержит "userdata" объекта из МТА.

Но если вернуться к предыдущему вопросу о существовании/несуществовании наследственности и полиморфизма, то его можно закрывать? И то, и другое существует и реально помогает людям.

По поводу библиотек. Я не использую библиотеки, для меня они слишком универсальны. И подозреваю, что их значение у тебя переоценено. Если ты думаешь, что какие-то библиотеки создают классы каким-то своим магическим образом, недоступным для тебя, ты ошибаешься. Они точно также имитируют создание классов, которых в Lua на самом деле нет.

Начнём с того, что я автор той библиотеки которая реализовывает ООП в таком виде как указанно по ссылке выше.

Все остальное я не совсем понял. Все созданные объекты являются "userdata" - всмысле в МТА, тогда да. А если ты имеешь в виду экземпляры класса в коде - то не факт. У меня объекты класса - это тоже таблицы, одна из ячеек которой содержит "userdata" объекта из МТА.

Но если вернуться к предыдущему вопросу о существовании/несуществовании наследственности и полиморфизма, то его можно закрывать? И то, и другое существует и реально помогает людям.

Мы говорим с тобой о разных вещах, ты уже сам и не заметил как ушел от темы, пытаясь мне доказать, что на Lua можно реализовать полноценное ООП. Спасибо, но зря стараешься, я это отлично знаю и давно уже реализовал всё необходимое. Но речь совершенно о другом.

Начнём с того, что я автор той библиотеки которая реализовывает ООП в таком виде как указанно по ссылке выше.

Ну отлично

Вот только воевать не надо начинать, в лучших традициях русскоязычных форумов, да?

Еще раз. Тобой было написано, что то, что есть в МТА - это сложно назвать ООП. И должно быть как минимум наследование, полиморфизм.

Создание своих классов не предусмотрено. То что сделали в МТА очень сложно назвать "ООП". То что вызов происходит через точку\двоеточие не значит, что это ООП.

Всё что и добавили в МТА - это всего лишь регистры для Lua позволяющие обращаться к userdata как к таблицам, т.е. вызов методов и доступ к членам. Больше ничего.

В ООП как минимум должно быть Наследование, Полиморфизм хотя бы. В идеале конечно бы и Инкапсуляция ещё.

Это действительно странное заявление, учитывая, что вся система эелементов в МТА построена с точки зрения наследственности. Element --> Ped --> Player.

Пример полиморфизма: player:setParent(object). То есть этот (один) метод выполняет разный код в зависимости от типа элемента.

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

И после того, как я спросил "К вопросу о существовании/несуществовании наследственности и полиморфизма, то его можно закрывать?" мне говорят, что я зря стараюсь, пытаясь что-то доказать и что я вообще ушел от какой-то темы.

Мне очень хочется верить, что причина спора просто в формулировках, а не в некомпетентности.

Речь шла о реализации собственных классов с помощью API MTA, ты видимо читаешь через строчку.

Речь шла о реализации собственных классов с помощью API MTA, ты видимо читаешь через строчку.

Это вопрос был следующим. То есть с первым все решено, все ок?

По поводу кастомных классов. Я не совсем понимаю, в чем именно сложность создавать свои классы с конструктором, деконструктором и т.п. С обращением к элементу по типу как в реализовано в МТА.

Есть же куча статей на всех языках по теме "реализация классов в Lua"

По поводу кастомных классов. Я не совсем понимаю, в чем именно сложность создавать свои классы с конструктором, деконструктором и т.п. С обращением к элементу по типу как в реализовано в МТА.

Есть же куча статей на всех языках по теме "реализация классов в Lua"

В том что это возможно только с использованием сторонних библиотек, которые нужно включать в каждый ресурс, а это костыль. Речь о реализации классов как таковых внутри самой МТА, без необходимости делать это своими силами.

По поводу кастомных классов. Я не совсем понимаю, в чем именно сложность создавать свои классы с конструктором, деконструктором и т.п. С обращением к элементу по типу как в реализовано в МТА.

Есть же куча статей на всех языках по теме "реализация классов в Lua"

В том что это возможно только с использованием сторонних библиотек, которые нужно включать в каждый ресурс, а это костыль. Речь о реализации классов как таковых внутри самой МТА, без необходимости делать это своими силами.

Это НЕ так! В сущности что такое класс в Lua? Это таблица, в полях которой может содержаться то, что в ООП-языке содержит настоящий класс - конструктор, деструктор, какое-то поведение и пр. Ну что мешает создавать эти таблицы?

Причем в сети действительно достаточно материала об этом! Хотя бы вот на хабре: http://habrahabr.ru/post/228001/

Господи. Как же до тебя не доходит? Перечитай тему.

Rocketman21, а почему библиотеки это костыль то? Во всяком случае даже если и костыль, что в этом такого?

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

В тех же плюсах часто применяются WxWidgets, Qt, Boost. А взять примером историю стандартной библиотеки(STL), она же прежде чем оказаться в стандарте, заинтересовала комитет и вообще она была создана прежде чем оказаться в стандарте, при том это было что-то новое.

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

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

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

fabervox, да я ни коим образом не против библиотек) Просто пытался объяснить GTA-Multiplayer.com что речь шла о встроенной в мта реализации классов, а не о том что это можно реализовать самому средствами луа.

А на свой первоначальный вопрос, заданный в первом посте, я ответ получил. Теперь найти бы нормальную библиотеку, самому делать в лом, да и времени нет особо…