AOClassLibrary.lua - бибилотека классов.

[Гость Demens]

0. ну про ИМХО я не буду ничего говорить, угрюмому бородатому дядьке это уже сложно видно осознавать. да и как вы нащитали 3/33... ааааа, подождите да вы обьявление каждого регистратора за отдельный пунк считали... ну ниче так... мне понравилось :-)))

1. Надо ПРИДУМАТЬ а потом помнить имена хэндлеров - чем вам не подходят вашиже указанные "САМИ ИМЕНА ИВЕНТОВ, скопированные из предоставленного разрабами МАНУАЛА"

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

3. ну при сложложной структуре будет у вас 5-10 таблиц по условиям которые тоже фиг знает как называть :-)

4. это уже про сарказм. а что плохо во "втором варианте" ???, я когото учил гдето чемуто? мнения от поучений суровым дядькам отличать некогда, бороду надо причесывать?

5. Мат часть? таблицы в луа? основной механизм полноценной жизни? ну я канечно не уверен, вам там виднее, но мне кажется что адресат шутку вполне адыкватно воспринял, в отличае от вас.

6. если вы не полюзуетесь ни одним из этих подходов, просветите дитей жаждущих знаний чем вы пользуетесь?

З.Ы. как то вы агрессивно настроены, бороду подполили случайно али еще какой казус случился? Боже сделай чтобы люди до 10 считать научились перед тем как браузер запустить.

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

ушол учить матчаст, ток вы не подскажите чего? логики, математики, проектирования, программирования, луа...

[ramirez]

Отлично, честь задета, диалог налажен. =)

Quote:

0. ну про ИМХО я не буду ничего говорить, угрюмому бородатому дядьке это уже сложно видно осознавать. да и как вы нащитали 3/33... ааааа, подождите да вы обьявление каждого регистратора за отдельный пунк считали... ну ниче так... мне понравилось :-)))

0. Объявление каждого ОБРАБОТЧИКА, а не регистратора. Неважно, придумал имя, или скопировал, все равно их надо вписывать/вставлять по одному в каждую регистрацию в отличие от. Потому и посчитал, это дополнительные имена, которых могло и не быть.

Quote:

1. Надо ПРИДУМАТЬ а потом помнить имена хэндлеров - чем вам не подходят вашиже указанные "САМИ ИМЕНА ИВЕНТОВ, скопированные из предоставленного разрабами МАНУАЛА"

1. На один ивент можно порегистрировать НЕСКОЛЬКО обработчиков, одним именем ивента не обойдешься в это случае, надо придумывать. Да и называть глобальную функцию как константу - себя же запутывать.

Quote:

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

2. Нет, в смысле идти туда, где порегистрировано остальное и руками добавлять еще регистрацию.

Quote:

3. ну при сложложной структуре будет у вас 5-10 таблиц по условиям которые тоже фиг знает как называть :-)

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

Quote:

4. это уже про сарказм. а что плохо во "втором варианте" ???, я когото учил гдето чемуто? мнения от поучений суровым дядькам отличать некогда, бороду надо причесывать?

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

Quote:

5. Мат часть? таблицы в луа? основной механизм полноценной жизни? ну я канечно не уверен, вам там виднее, но мне кажется что адресат шутку вполне адыкватно воспринял, в отличае от вас.

5. Адресат - молодец, но дед Оккам его страсти не одобрил бы. Матчасть, да. И да, про Lua мне виднее.

Quote:

6. если вы не полюзуетесь ни одним из этих подходов, просветите дитей жаждущих знаний чем вы пользуетесь?

6. Головой. А также объектами, псевдо-классами, множественным наследованием, кастомизируемыми виджетами и контроллером эффектов.

Quote:

З.Ы. как то вы агрессивно настроены, бороду подполили случайно али еще какой казус случился? Боже сделай чтобы люди до 10 считать научились перед тем как браузер запустить.

- Я был агрессивен, это факт. Но по делу, считаю. Тут хором все подсказывают, где Вы ошибаетесь в своем мнении, но как-то это упорно игнорируется. Вот, попробовал на пальцАх показать.

Quote:

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

- В моем аддоне 38 файлов скрипта, суммарно 4.5к строк, выверты не практикую. И выкладывать пока не планирую.

Quote:

ушол учить матчаст, ток вы не подскажите чего? логики, математики, проектирования, программирования, луа...

- Дети, жаждущие знаний - учатся самостоятельно. Обычно тому, чего жаждут.

[Mankubus]

Можно поинтересоваться, что за такой аддон Вы пишете?

[ramirez]

Да, это замена стандартного интерфейса своим, насколько это возможно. Это дьявольски интересно(с).

[Гость Demens]

не обольщайтесь, честь не задета, диалог способ учится.

Quote:

1. На один ивент можно порегистрировать НЕСКОЛЬКО обработчиков, одним именем ивента не обойдешься в это случае, надо придумывать

1. можно и НЕСКОЛЬКО, но в "промышленном" подходе несколько обработчиков тоже в лоб в таблицу не убихаеш однако.

Quote:

2. Нет, в смысле идти туда, где порегистрировано остальное и руками добавлять еще регистрацию.

2. аналог - добавление таблиц при необходимости уловия и/или нескольких обработчиков.

Quote:

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

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

Quote:

4. Он ненужно переусложнен, этот вариант, и дальнейшее его развитие стремительно приводит к ценному пушному зверю.

4. ну там вроде написанно что оно излишне переусложнено, но зато даёт максимум универсализации, там по сути вообще помнить ничего не надо, 1 таблица, 1 функция регистрации, единая структура для всех обработчиков.

Quote:

5. Адресат - молодец, но дед Оккам его страсти не одобрил бы. Матчасть, да. И да, про Lua мне виднее.

5. сдается мне там ключевое слово было "шутка", но это можно списать на ваше плохое настроение :-)

Quote:

6. Головой. А также объектами, псевдо-классами, множественным наследованием, кастомизируемыми виджетами и контроллером эффектов.

6. можно попросить пример? ну что-нибудь на подобии выше рассмотренных, простенький такой, не для 38ми скриптов с 4,5к строк, а для среднего по размерам аддона который в разы меньше, думаю это вы и без меня понимаете.

Quote:

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

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

Quote:

- В моем аддоне 38 файлов скрипта, суммарно 4.5к строк, выверты не практикую. И выкладывать пока не планирую.

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

Quote:

- Дети, жаждущие знаний - учатся самостоятельно. Обычно тому, чего жаждут.

вот они собсветнно самостоятельно и учатся(а некоторые на них срываются ;-) ), только мне вот непонятно зачем изобретать велосипед самому если можно обсудить уже готовый чужой и учесть его возможные недостатки?

[ramirez]

Ну раз не задета, будем жить.

Quote:

1. можно и НЕСКОЛЬКО, но в "промышленном" подходе несколько обработчиков тоже в лоб в таблицу не убихаеш однако.

Зачем в одну-то? Суть нескольких как раз в том, чтоб их в разных случаях использовать. Если же в одном, то проще один обработчик писать.

Quote:

2. аналог - добавление таблиц при необходимости уловия и/или нескольких обработчиков.

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

Quote:

4. ну там вроде написанно что оно излишне переусложнено, но зато даёт максимум универсализации, там по сути вообще помнить ничего не надо, 1 таблица, 1 функция регистрации, единая структура для всех обработчиков.

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

Quote:

6. можно попросить пример? ну что-нибудь на подобии выше рассмотренных, простенький такой, не для 38ми скриптов с 4,5к строк, а для среднего по размерам аддона который в разы меньше, думаю это вы и без меня понимаете.

Все расширения тоже написаны на Луа, а на халяву раздавать собственные наработки не готов. И в маленьком примере все эти расширения бессмысленны, без них быстрее и проще. Если вкратце, то в базовом классе заведена обвязка для метода-генератора пачки собственных обработчиков для каждого объекта, сам метод переопределяется в классах-наследниках и вызывается в теле widget:Show( bool ) для регистрации или отписки от событий. В основных скриптах только определяешь обработчики и все. Код обработчика пишется только однажды, а работает в 48 местах сразу. Фактически, это развитие идеи "промышленного" подхода; не фонтан, но хватает с головой.

Quote:

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

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

Quote:

вот они собсветнно самостоятельно и учатся(а некоторые на них срываются ;-) ), только мне вот непонятно зачем изобретать велосипед самому если можно обсудить уже готовый чужой и учесть его возможные недостатки?

Да, давайте поспорим о вкусе устриц с теми, кто их ел. =)

[Гость Demens]

Quote:

В аддона среднего/большого размера - очень выгоден. В аддоне, реагирующем на одно событие - совсем не нужен.

вот, вот оно, нинада стрелять по мухам из базуки :-) уря

Quote:

Да, давайте поспорим о вкусе устриц с теми, кто их ел. =)

вкус это вкус, вы же понели что я имел ввиду :-)))

Quote:

... Если вкратце, то в базовом ...

спасибо за развернутый ответ, собственно нечто подобное я и предпологал.

З.Ы. спасибо за конструктивный диалог, было интерестно.

[DarkMaster]

Обновил код библиотеки сделал 1 базовый класс TWidget. Данный класс обертка расширяет функционал стандартных Ниваловских виджетов. И позволяет быстро и просто управлять виджетами. Класс включает в себя:

• Создание новых обьектов, как статических( из xdb ) так и динамических по Desc

Перетаскивание - просто включаем\выключаем перетаскивание для данного виджета. Все что касаеться перетаскивания отслеживаеться библиотекой, так же сохраняетсья позиция виджета после лог\логаут.Собранны полезные функции - изменения размера, позиции, установки цвета и т.д.Пожалуй самое главное - данный класс позвоялет получить доступ к "детям"-child, с помошью функции GetChildByName( Name ) вы получаете обьект такого же типа TWidget со всеми свойсвами и методами, от которого также можна взять child, что решает проблему вложенности обьектов интерфейса.

Так же при атачил к посту пример в котром наглядно демонстрирую удобство работы с библиотекой. AOClassLibraryExample

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

Пример:

Code:

--------------------------------------------------------------------------------------------------------------------------

Global( "TTextView", {} )

--------------------------------------------------------------------------------------------------------------------------

function TTextView:CreateNewObject( WidgetName )

local NewObject = TWidget:CreateNewObject( WidgetName )

return NewObject

end

function TTextView:SetText( KeyName, Text )

self.Widget:SetVal( KeyName, Text )

end

Надеюсь в дальнейшем билиотека будет расширяься и дополняться не только мной. *)))

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

[ramirez]

Пошарил тут в древних скриптах разрабов и извлек, предварительно почистив. Получилось забавно:

Code:

--------------------------------------------------------------------------------

do

local function mergemetatable( tab, mt )

local _mt = getmetatable( tab )

_mt = type( _mt ) == "table" and _mt or {}

for k, v in mt do

_mt [ k ]  = v

end

setmetatable( tab, _mt )

return tab

end

------------------------------------------------------------------------------

local function replicate( cl, obj )

return mergemetatable( obj or {}, { __index = cl } )

end

------------------------------------------------------------------------------

function Class( name, proto )

Global( name, mergemetatable( proto or {}, { __call = replicate, __name = name } ) )

end

end

--------------------------------------------------------------------------------

Что это дает? Это дает нам единственную глобальную функцию Class, которая позволяет объявить любую таблицу с набором свойств и методов "классом".

Code:

local base = { a = 2 }

function base:GetA()

return self.a

end

Class( "CBaseObject", base )

Что дает нам такой "класс"? Он позволяет плодить объекты, имеющие прототипом это самый класс.

Code:

local object = { a = 5 }

CBaseObject( object )

LogInfo( "a = ", object:GetA() ) -- << a = 5

Можно написать и суперсжато, все равно пример выглядит по-идиотски =):

Code:

LogInfo( "a = ", CBaseObject{ a = 5 }:GetA() ) -- << a = 5

Будет работать и вот такое:

Code:

LogInfo( "a = ", CBaseObject{ b = 5 }:GetA() ) -- << a = 2

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

Еще можно от такого класса наследоваться.

Code:

local child = CBaseObject{ a = 12, b = 4, c = 8 }

function child:GetB()

return self.b

end

function child:GetC()

return self.c

end

Class( "CBaseChild", child )

То есть, берем и тупо объявляем классом расширенный и дополненный "объект класса" CBaseObject.

На его основе также можно настрогать объектов.

Code:

local childobject = CBaseChild{ c = 108 }

LogInfo( "a = ",childobject:GetA() ) -- << a = 12

LogInfo( "b = ",childobject:GetB() ) -- << b = 4

LogInfo( "c = ", childobject:GetC() ) -- << c = 108

Советую внимательно присмотреться на предмет развития библиотеки.

[DarkMaster]

Да я тоже нашел это в скриптах. Вообщем-то Луа язык не строгий и как говориться "за ухом можно почесаться 175 способами" *))) По сути измениться лишь способ обьявления. Можно так как я реализовал, можно так как делает это Нивал. В действительности же нужно наращивать функциональные возможности библиотеки. Вот например кто то приводил пример универсальной функции установки текста - помоему это был ты Ramirez - ну так взял бы и доработал этот моент в рамках билиотеки добавил бы новый класс или в уже существуюший TWidget. Просто разные "автоматизации" кода встречаютсья отрывочно то в одном то в другом аддоне. Их нада собрать, вылезать, отладить, стандартизировать, обьеденить в один подключаемый файл. Думаю не нужно говорить что как это упростит разработку как нам самим так и новым модмейкерам *) Ведь согласиль удобно просто сказать виджету - ты перетаскиваемый и не пареться как имено он перетаскиваеться и сохраняет свои позиции после релога. А это базируетсья на функциях, кторые публиковал SLA, просто дороботанных и внедренных в TWidget.

Вот вопрос на засыпку - возможноли прикреплять разные реакции к однотипным ( созданным по 1му Desc-у ) обектам ?

Пример у меня есть кнопка А у нее в XDB прописана реакци на клик AReaction - если я буду создавать кнопки динамически по ее типу ( CreateByDesc ) то у созданных кнопок будет таже самая реакция AReaction. Это как то не удбно блин *))) Хотелось бы добиться функционала VCL - могу подключить к событиы OnClick свой обработчик. Типа

Button1.OnClick = Func1, а Button2.OnClick = Func2, хотя оба созданны по типу Button.

Any ideas how do it ? *)))) Ramirez - ты вроде постами выше намекал на то что чета придумал с обработчиками, не скупись делись если есть чем ! Дополни библиотеку или приведи пример и я сам дополню.

[ramirez]

Quote:

Да я тоже нашел это в скриптах. Вообщем-то Луа язык не строгий и как говориться "за ухом можно почесаться 175 способами" *)))

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

Quote:

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

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

Quote:

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

Наращивать надо с умом. У виджетов и так дофига всяких методов работы с ними, зачем нужны обертки для работы с их потомками? Возьми ссылку на самого потомка и работай непосредственно с ним.
Дорабатывать в функции нечего, просто бери и пользуйся, как хочешь. Прелесть Lua как раз в том, что она без изменений может быть и методом TWidget и просто функцией библиотеки утилит.

Quote:

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

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

Quote:

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

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

Quote:

Вот вопрос на засыпку - возможноли прикреплять разные реакции к однотипным ( созданным по 1му Desc-у ) обектам ?

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

Quote:

Button1.OnClick = Func1, а Button2.OnClick = Func2, хотя оба созданны по типу Button.

Отвечает капитан Очевидность: Ну, для того, чтоб виджету добавить метод, нужно чтоб тип виджета в Lua был не "userdata", а "table". Других путей нет. TWidget вроде как раз этим и занимается, так что тебе по идее видней, как его надстраивать. Но регистрировать все равно придется, хотя бы на инициализации.

Quote:

Any ideas how do it ? *))))

Идеи - пожалуйста! =)
1. Сделать скрипт, автоматически пробегающийся по всему дереву виджетов и подменяющий их прокси-табличками, с выведенными наружу методами-обертками от исходных виджетов. Ключ к успеху - метатаблицы и widget:GetNamedChildren().
2. Написать базовый класс виджета для этих прокси-табличек, в котором залудить функционал автоматической регистрации объявленных в классах-наследниках обработчиков реакций. Ну и ивентов заодно. =)
3. Всякий там ДрагнДроп, универсальные фукции для текстов и прочее реализовывать в классах-наследниках, разработав для этого единую архитектуру наследования.

Quote:

Ramirez - ты вроде постами выше намекал на то что чета придумал с обработчиками, не скупись делись если есть чем ! Дополни библиотеку или приведи пример и я сам дополню.

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

[Гость LeonPRO]

Попробуйте по старинке, в цикле создать 10000+ виджетов, а затем дестройнуть, и следить за памятью.

Или создавать - дестроить по 2-10 виджетов в очень большом цикле (мне кажется это будет лучше, так как неизвестно что сделает клиент с памятью, если его попросить создаьт 10000 виджетов ))

[DarkMaster]

Quote:

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

ппц *)))) Ты денги что ли рубить собрался на своих наработках, для АО *)))). Как говорил классик - "колхоз - дело доброваольное" и ты конечно не обязан, но по сути для конечного пользователя, все твои посты выше лишь расуждения о сферическом коне в вакууме, если ты никоим образом не помогаешь развитию идеи *))) Нас не много - модмейкеров для АО, а за идею создания библиотеки пока радею вообше только я 1. Да мои решения не идеальны - ты это видишь, возможно твои реализации были бы лучше - но пока они выраженны в форме советов и не более *) "Назвался грузбдем - полезай в кузов" - взялся бы да сделал что то, предложил бы свой реализованный наглядный вариант. А то как то это - выглядит не коректно что ли *))) не подумай я не против твоих замечаний просто не могу понять причину нежелания что то сделать раз ты умеешь лучше и больше ( если конечно умеешь, так как ниодной реализации пока что от тебя не видно, лишь общие формулировки ) *)))))

Quote:

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

Эмм а я как бы не говорил - "давай сгребем все в 1 файл" *)))) Это всеголишь начало и очень небольшое. Есть такая библиотека ACE для ВОВ. Вот в идеале к чему нада стермиться - там масса всего и реализованно все очень хорошо и удобно. Если не знаешь погугли по этому вопросу.

Quote:

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

А чем мой текущий то не правльный ? Вроде иимено в этом направлении и ведеться работа - собрать в 1 классе удобные фичи для работы с виджетом *))).

Quote:

Наращивать надо с умом. У виджетов и так дофига всяких методов работы с ними, з ачем нужны обертки для работы с их потомками? Возьми ссылку на самого потомка и работай непосредственно с ним.
Дорабатывать в функции нечего, просто бери и пользуйся, как хочешь. Прелесть Lua как раз в том, что она без изменений может быть и методом TWidget и просто функцией библиотеки утилит.

Дело тут в том что я получаю обьект типа userdata ниваловский и например если я хочу изменить размер то я вынуждет писать столбик кода который изменяет размер типа:

Code:

local wtChildWidget = ..... получаем виджет стандартного "Ниваловского" типа ....
local wtPlacment = wtChildWidget:GetPlacment()
wtPlacment.sizeX = newW
childwidget:SetPlacment( wtPlacment )

и так далее, а получив от родителя типа TWidget дочерний виджет в форме TWidget я просто пишу

Code:

local ChildWidget = MainWidget:GetChildByName( "Name" )
ChildWidget:SetWidth( newW )

как бы, упрошение кодинга на лицо, нэ ? *)))))) И кстати, если у нас в TWidget есть масса, методов типа DND они тоже просто и удобно доступны, без лишнего геморойя *)

[ramirez]

Quote:

ппц *)))) Ты денги что ли рубить собрался на своих наработках, для АО *)))).

С чего ты взял, что они для AO? =) Они вообще. Потратил пару лет, если чо. А нивальское всем доступно, декомпилируй и вперед.

Quote:

Эмм а я как бы не говорил - "давай сгребем все в 1 файл" *))))

Двумя постами выше говорил:

Quote:

Их нада собрать, вылезать, отладить, стандартизировать, обьеденить в один подключаемый файл.

Quote:

А чем мой текущий то не правльный ?

Твой текущий - правильный, но сильно узконаправленный, громоздкий и сырой.

Quote:

Дело тут в том что я получаю обьект типа userdata ниваловский и например если я хочу изменить размер то я вынуждет писать столбик кода...

Ты походу и не понял, о чем я. А твой пример без TWidget решается так:

Code:

local function clone( t, o )
for k, v in pairs( t ) do
o [ k ]  = v
end
return o
end
function widgetlibrary.SetPlacementPlain( widget, placement )
widget:SetPlacementPlain( clone( placement, widget:GetPlacementPlain() ) )
end
--------------------------------------------------------------------------------
-- Использование:
local widget = parent:GetChildChecked( "widgetName", true )
widgetlibrary.SetPlacementPlain( widget, { sizeX = 480, posX = 64 } )

Вроде так же получилось, только оберток нет никаких, и метод один вместо восьми. А если хочется круто, то про прокси-таблички я выше писал.

[DarkMaster]

Quote:

Твой текущий - правильный, но сильно узконаправленный, громоздкий и сырой.

Узконаправленный - да но "грамоздкий и сырой" - это то в чем появляеться ? Я не понимаю как узконаправленное дествие которое относиться к 1-му типа данных можно ( нужно ? ) делать универсальным ? Есть виджет и есть дествия над ним узконапрвленные, имеющие смысл лишь в приложении к типу виджет - есть 2 варианта автоматизации - писать класс обертку или писать набор функций. Выбрать тот или иной подход - это просто дело вкуса, кто то любит ООП подход, кто то поклоник структурного программирования. Универсализация узконаправленных действи - это как раз ненужное усложнение. Я не вижу разницы которая повышает производительность или удобства использования при вот таких реализациях:

Code:

local function clone( t, o )
for k, v in pairs( t ) do
o  [ k ]   = v
end
return o
end
function widgetlibrary.SetPlacementPlain( widget, placement )
widget:SetPlacementPlain( clone( placement, widget:GetPlacementPlain() ) )
end
--------------------------------------------------------------------------------
-- Использование:
local widget = parent:GetChildChecked( "widgetName", true )
widgetlibrary.SetPlacementPlain( widget, { sizeX = 480, posX = 64 } )
.
.
.
function TWidget:SetWidth( newW )
   local Placment = widget:GetPlacmentPlace()
   Placment.sizeX = newW
   widget:SetPlacementPlain( Placment )
end
-- Использование:
local widget = TWidget:CreateNewObject( "widgetName" )
widget:SetWidth( 480 )

Разная реализация, суть одна и таже, удобство использование ~одинаковы. Так что тут я думаю просто дело вкуса.

Quote:

только оберток нет никаких, и метод один вместо восьми

Ну а у меня в классе ты где увидел 8мь методов для установки размера ? 3 метода разнесенных в разные функции для удобство восприятия и написания кода - SetWidth, SetHeight, SetPosition - использование разных имен делает исходный код более логичным и четабельным, нежели использование для этого метода с одним и темже названием, пример:

local widget = TWidget:CreateNewObject( "widgetName" )
widget:SetWidth( 480 )
widget:SetHeight( 100 )
widget:SetPosition( 100, 100 )

Более строго и и понятно, при просмотре кода нежели

local widget = parent:GetChildChecked( "widgetName", true )
widgetlibrary.SetPlacementPlain( widget, { sizeX = 480 } ) - меняет ширену
widgetlibrary.SetPlacementPlain( widget, { sizeY = 100 } ) - меняет высоту
widgetlibrary.SetPlacementPlain( widget, { posX = 100, posY = 100 } ) - меняет позицию

По факту выполнения одно и тоже, но по факту чтения второй вариант менее удобен для восприятия особено если челоек не знаком с структурой работы библиотеки. Говорящие имена - понятнее нежели SetPlacementPlain - если так параметры заданы то делает то-то, если по другому то что-то другое. Нэ ?

[ramirez]

Нэ. Распишу подробней, но с конца.

Quote:

По факту выполнения одно и тоже, но по факту чтения второй вариант менее удобен для восприятия особено если челоек не знаком с структурой работы библиотеки

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

Quote:

Ну а у меня в классе ты где увидел 8мь методов для установки размера ? 3 метода ...

Остальные ты не написал. Это SetPositionHigh, SetAlignX, SetAlignY, SetSizingX, SetSizingY. Не говоря о геттерах, типа забытого GetPosition. Пока библиотекой пользуешься ты один - канает. Но если претендуешь на повсеместное использование библиотеки всеми, тогда - полный функционал.

Разработчики из Нивала придумали структуру plain placement не потому, что такие мудаки, а потому что так было нужно. Она полностью описывает позиционирование виджета на экране, включая все случаи изменения разрешения экрана и размеров виджетов. Обертки SetWidth и т.п. не затрагивают и четверти этого функционала.

В моем случае можно написать одной строчкой:

Code:

widgetlibrary.SetPlacementPlain( widget, { sizeX = 480, sizeY = 100, posX = 100, posY = 100, highPosY = 53, alignY = WIDGET_ALIGN_BOTH } )

В твоем - облом.

А особенно удобно placement генерить, хранить и передавать в другие функции агрументом. Например, в случае драг'н'дропа логичные и читабельные обертки SetWidth, SetPosition и т.п. бесполезны.

Quote:

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

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

Quote:

Узконаправленный - да но "грамоздкий и сырой" - это то в чем появляеться ? Я не понимаю как узконаправленное дествие которое относиться к 1-му типа данных можно ( нужно ? ) делать универсальным ? Есть виджет и есть дествия над ним узконапрвленные, имеющие смысл лишь в приложении к типу виджет - есть 2 варианта автоматизации - писать класс обертку или писать набор функций.

Только 2 варианта? А можно совсем заместить виджеты своими объектами и делать с ними что угодно, например. И обертка, и библиотека сразу будет.

Громоздкий - ибо толпа ненужных функций. Не нужны:

Code:

GetChildByName -> widget:GetChildUnchecked( name, recursive )

GetChildByIndex -> widget:GetNamedChildren() [ ChildIndex ] 

SetColor -> widget:SetBackgroundColor( color )

GetChildCount -> GetTableSize( widget:GetNamedChildren() )

Hide -> Show( false )

ShowAllChild, HideAllChild -> parent:Show( bVisible )

CreateNewObjectByDesc, GetDesc -> в нивальских старых скриптах есть фабрика виджетов с полным функционалом.

SetPosition со-товарищи - см. выше.

Что осталось?

Сырой - это недописанный. Везде используется if self.Widget then, но при этом львиная доля стандартных методов виджетов не обернута. Если их предполагалось использовать как WidgetTable.Widget:<имя метода>( агрументы ) без проверки, то на кой это все было вообще городить? Да и поддержка хреновой горы оберток при постоянно меняющемся API никогда не даст дописать. И по-прежнему не вижу обещанных классов.

Сырой - криво написанный. GetChildByName через GetNamedChildren и цикл с условием - шедевр. GetChildByIndex через такой же цикл, но с рукопашным итератором - еще более шедевр. Индусы рыдают. =) Распил Show на Show и Hide, и при этом совмещенные в MakeMovable DNDReg и DNDUnreg. Прочие мелочи, вроде забытых переменных в ShowAllChild и общих грамматических ошибок. Про вынужденно прикрученный сбоку драгНдроп - ваще отдельная песня.

Я понимаю - незнание Lua, практик программирования, нехватка времени и т.д. Но ведь и не гонит никто вроде бы, не заставляет сразу писать библиотеку для всех. Вот так, блин, - всего-то хотел советов накидать, а в результате вынужден гнобить. =)

P.S. Вот написал бы кто отлаженный TableToString, цены б ему не было. Можно даже награду объявить.

[DarkMaster]

8) Начну комментировать тоже с конца:

Quote:

Я понимаю - незнание Lua, практик программирования, нехватка времени и т.д. Но ведь и не гонит никто вроде бы, не заставляет сразу писать библиотеку для всех. Вот так, блин, - всего-то хотел советов накидать, а в результате вынужден гнобить. =)

1. Стили выражения мыслей:

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

Quote:

GetChildByName через GetNamedChildren и цикл с условием - шедевр.GetChildByIndex через такой же цикл, но с рукопашным итератором - еще более шедевр. Индусы рыдают. =)

"Тонкий" намек на "толстую реализацию" - ну и что ? Прочитав это я что должен понять ? Что я криворуки неудачник ? *) В чем смысл данного коммента ? Где тут конструктив по сабжу ? Если ты умеешь лучще, видишь как нужно сделать правельно - конкретезируй, а иначе это выглядит - не коректно *)))

2. Public library - это бииблиотеки для широких масс, при проектировании которых программисты обязанны стремиться к максимальной простоте восприятия кода, максимально простой и интуитивно понятной читабельности, при минимальной потери производительности. АПИ для разработки аддонов к игре - это иммено такая библиотека. При проектировании во глову угла должено ставиться удобство использования до предела когда удобство идет в ущерб производительности. Чего в АО АПИ нет и в помине - не документированное, своеобразное, кострированное ( это я про ВСтринг и не только ), без адекватной возможности реализовать ингейм дебаг. И иммено поэтому хочеться сделать надстройку над этим АПИ, в виде собственной библиотеки функций и классов.

Quote:

Разработчики из Нивала придумали структуру plain placement не потому, что такие мудаки, а потому что так было нужно.

Нужно кому ? Разработчикам Нивала ? А рядовым пользователям библиотеки - это нужно ? Если да то где в сопроводительной документации - простой пример доходчиво обьясняющий что, как, куда, зачем, почему, при работе с размерами и положением виджета. Нету = халатность. Намеки типа - несложно, разберитесь сами - это не выход, а просто пествование лени. Твоими же словами камень в огород Нивала:

Quote:

Пока библиотекой пользуешься ты один - канает. Но если претендуешь на повсеместное использование библиотеки всеми, тогда - полный функционал.

Нормально спроектированная библиотека должна предостовлять, различные варинты решения задачи. Соотвествено в ней должны быть реализованны методы как предлогаю я ( которые просто пришил к нам из массы других библиотек и примеров кода, методы Set\Get Position, Width, Height, ByName и т.д проктически стандарт и когда работаешь с новым АПИ или библиотекой на подсознательном уровне ищещ их, ну уж ни как не SetPlacmentPlace ) и методы как предлогаешь ты ( Да возможно более функционально, ну а нужно ли ? Это как раз тот пример когда функционалом можно пожертвовать ради читабльности ). Просто иметь и то и то варинт - кому как будет удобнее тот так и будет использовать.

3.

Quote:

Громоздкий - ибо толпа ненужных функций. Не нужны:

Толпа "ненужных" функций не мешает *))). Напрмиер GetChildByName, GetChildByIndex - в некторых случаях есть необходимость получить Чилда по имени а в некоторых по Индексу. Пример из практики.

4.

Quote:

Сырой - это недописанный. Везде используется if self.Widget then, но при этом львиная доля стандартных методов виджетов не обернута.

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

Итог: Уважаемы комрад Ramirez - если уж взялись "учить", делайте это хорошо !!! Хотите помочь - помогайте, а не "гните пальцы" в стиле "я умный - а ты индус". Ну а если не можете себя сдерживать в остротах - оборачивайте это в шутку хотябы. Не хотите конкретно кодить для библиотеки - по крайне мере старайтесь примерами подкреплять. За мысли вам +, есть много чему у вас по учиться, за выражение ваших мыслий --, с вами не приятно общаться. На правах ИМХО.

[Гость wait]

Quote:

P.S. Вот написал бы кто отлаженный TableToString, цены б ему не было. Можно даже награду объявить.

чем не устраивают стандартные?
1. lua (table.tostring)
http://lua-users.org/wiki/TableUtils
2. nival (TableToString)
Interface\Ingame\ContextLayoutManager\ScriptContextLayoutManagerPlugIn.lua

[ramirez]

1. нету такой в AO.

2. нет защиты от рекурсивных ссылок.

[Гость wait]

ну так возьми из первого линка, вставь в общую библиотеку (в тот же SampleCommon или свою) и используй

[ramirez]

1. "Гнобить" не хотел. Нравится твоя инициатива и совсем не нравится реализация. Пытался подсказывать, не указывая недостатков. Если кратце, пообщались так:

- DarkMaster: давайте пользоваться моей библиотекой!

- kosh, Valltron, Ramirez: Сходу ниасилил. Сомневуха берет. Без нее пока проще.

- DarkMaster: Да не, смотрите как клево!

- Valltron: Да не. Вот на ивенты хитро подписываться - это клево!

... Эскапада с Demens'ом

- DarkMaster: Я тут дописал, теперь еще лучше.

- Ramirez: А вот смотри, классы по-Нивальски - прикольные!

- DarkMaster: Да один хрен, дело вкуса. Ты про реакции давай колись.

- Ramirez: Нифига, оно по возможностям шире. Про реакции - облом, только в обход.

- DarkMaster: Не гони, нету разницы. Смотри, какой SetWidth простой!

- Ramirez: Он лишний, там placement есть.

... И понеслась.

Ты не понимал про "узконаправленную, громоздкую и сырую" - я расписал. Аргументов там достаточно. Не нравятся мои - поспрашивай еще кого-нибудь из камрадов, кто-нибудь библиотеку пытался использовать?

Нормальный менеджер НЕ решает за подчиненных их задачи, иначе они ему на шею сразу сядут. И слова "истенна" в языке нет. =)

Quote:

"Тонкий" намек на "толстую реализацию" - ну и что ? Прочитав это я что должен понять ? Что я криворуки неудачник ? *) В чем смысл данного коммента ? Где тут конструктив по сабжу ? Если ты умеешь лучще, видишь как нужно сделать правельно - конкретезируй, а иначе это выглядит - не коректно *)))

Дублирую предыдущий пост:

Code:

GetChildByName -> widget:GetChildUnchecked( name, recursive )

GetChildByIndex -> widget:GetNamedChildren() [ ChildIndex ]  

SetColor -> widget:SetBackgroundColor( color )

GetChildCount -> GetTableSize( widget:GetNamedChildren() )

Hide -> Show( false )

ShowAllChild, HideAllChild -> parent:Show( bVisible )

Расшифровываю: в строках после "->" дана ПОЛНАЯ замена твоим функциям. Как еще конкретизировать?

2. С твоих слов, цель мудаков из Нивала - бесконечно осложнять тебе жизнь. Так вот, их цель - игру сделать и тебе продать. И placement - он, чтобы виджетами нивальскими пользоваться. Если пользуешься - разберись. Обертка сейчас - хуже. Аргументы уже приводил.

3. Толпа ненужных функций мешает знакомиться с твоим кодом. Из чего возникло "ниасилил" у некоторых камрадов.

4. Подход реализации А тупиковый, развивать бессмысленно. Кодер Х высказывает альтернативные идеи. С примерами. Идеи игнорируются. Кодера Х активно разводят на готовый код. Кодеру Х реализация А не нужна. Он все равно должен что-то писать?

Итог: Учить - и не брался, учиться извольте сами. Я здесь ссылки приводил на Lua.org, хоть один камрад там побывал? Все приведенные мной примеры кода вызывали в ответ непонимание и "гнутие пальцев" в стиле "можно и так, просто дело вкуса". Развернутые попытки показать разницу - либо игнорируются, либо вызывают недовольство. Ну ок.

[ramirez]

Мне не нада, у меня есть. =)

Upd: там много интересного, но почти все под 5.1.x. Для таблиц string.match в 5.0.x не нашел, хотя оно там вроде не особо и надо... надо посмотреть, короче. =)

[SLA]

Я пользуюсь слегка украшенной версией функции DarkMaster'а:

Code:

function LogInfoTable( strName, ptrData )

LogInfo( "----------------------------------------" )

if ptrData then

LogInfo( strName, " = {" )

for DataName, DataValue in ptrData do

LogInfo( "    ", DataName, " = ", DataValue ) 

end

LogInfo( "}" )

else

LogInfo( strName, " = nil" )

end

LogInfo( "----------------------------------------" )

end

Возможно, её можно объединить с LogInfo(), добавив проверку типа данных

if type(ptrData) == "table" then

но мне лень :Р

Рекурсия? Хм.. Запросто можно сделать.

[ramirez]

Тестом на рекурсию пусть будет безбаговый вызов TableToString( _G ).

[DarkMaster]

Quote:

Не нравятся мои - поспрашивай еще кого-нибудь из камрадов, кто-нибудь библиотеку пытался использовать?

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