Скриптование

[Malandrinus 611]

 

 

мне категорически не нравится вот такое вот:

Я тут совсем не понял тебя. Что за "простыня" тебе не нравится? Судя по всему, ты противопоставляешь менеджер, сделанный на уровне модуля, такому же, сделанному в виде объекта класса. Я правильно понял? Или не нравится что-то другое?

[Dennis_Chikin 3 658]

Пример ООП ради ООП, который не дает ничего, кроме много строк. К вопросу о "вижу предрассудок".

[Zander_driver 10 166]

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

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

Если разрабатывается нечто сложное, есть некоторый выигрыш в том чтобы даже просто получение поля класса, простой переменной, оформлять в виде метода, и через метод же получать. Т.е. прикинуться что у нас внутренние поля объекта не публичны, а приватны вообще, и нам на них методы нужны. Понятно что в Луа это не так, но что мешает сделать так? Да ничего не мешает. Там где надо. Так зачем же это нужно? а мало ли, сегодня нам нужно просто поле хранящееся в объекте, а завтра нам надо будет повесить на него какую то проверку, или совершить какие то вычисления-преобразования. внести в возвращаемое методом значение поправку, и т.д. и т.п.

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

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

Ах да, про монстриков моих, я так понял, кроме "монстровидны" другого конструктивного негатива ждать уже не стоит?

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

Изменено 14 Февраля 2015 пользователем Zander_driver

[Dennis_Chikin 3 658]

Предмет обсуждения пока что вполне сферичен и в вакууме. Будет что пощупать руками - будем посмотреть.

 

self.base.statics[self.downbtn]:LMouse(function()
        local wnd = mag_ref_support.GetWND()
        wnd:DescrWndUp()
    end) -- я ж понятия не имею, что оно делает, и зачем.

Изменено 14 Февраля 2015 пользователем Dennis_Chikin

[Zander_driver 10 166]

я ж понятия не имею, что оно делает, и зачем.

Идет по адресу self.base.statics - там у нас таблица. далековато лежит, да. Ну вот так.

Из этой таблицы берем значение по ключу, который у нас хранится в self.downbtn

Значение той таблицы оказывается юзердата, объект класса. Сейчас неважно какого, важно что у этого класса есть метод LMouse.

Вот добравшись до объекта, мы у него этот метод и вызываем. А в качестве аргумента, ему, методу, передаем функцию.

начиная от слова function и заканчивая словом end, написана собственно передаваемая функция "как есть".

 

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

Изменено 14 Февраля 2015 пользователем Zander_driver

[Malandrinus 611]

 

 

ООП ради ООП, который не дает ничего, кроме много строк.

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

 

Кстати о птичках. Это как раз тот пример, где крайне уместно было бы применение системы событий. Вместо прописывания этих прямых вызовов, модуль погоды (или объект класса погодного менеджера) можно было бы подписать на соответствующие события. При этом собственно не потребовалось бы менять биндер вообще, так что и вопрос с простынёй бы не стоял. В OGSE так и сделано.

[Dennis_Chikin 3 658]

В этом конкретном примере функция нужна ровно одна. Чтобы там внутри что-нибудь сделалось. "Когда-нибудь в свободное время". И, соответственно, строка нужна тоже одна. То есть, не нужны ни __init(), ни reset(), ни загрузки/сохранения. Ни, соответственно, "получать" и хранить сам "менеджер".

Изменено 14 Февраля 2015 пользователем Dennis_Chikin

[Zander_driver 10 166]

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

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

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

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

Вообще присмотревшись к примеру, который привел DC, я понял что мне самому в нем не нравится. weather_manager создается как поле внутри биндера актора. нафига, спрашивается? Вот это действительно Bad Idea имхо.

[Desertir 202]

 

self.reactions[self.data[a].type](self.data[a], SCAS, SCAM)

 

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

local data_a = self.data[a] --data_a тоже назвать поинформативнее
self.reactions[data_a.type](data_a, SCAS, SCAM)

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

 

local obj = (function()
    local o = {}
    local v = 0;
    o.get_value = function()
        return v
    end
    return o
end)()
print(obj.o)
print(obj.get_value())

И делать их надо во время загрузок-сохранений актора. поидее.

Ну не знаю. Получается то, что загружается. должно зависеть от актора -> погода зависит от актора Изменено 14 Февраля 2015 пользователем Desertir

[xStream 86]

Наглядный пример ООП ради ООП... в реализации без архитектуры :-)

Изменено 14 Февраля 2015 пользователем xStream

[Zander_driver 10 166]

Что бы я сделал, так это переименовал переменную "а" в что-то более информативное

Это счетчик цикла, если что.

local data_a = self.data[a] --data_a тоже назвать поинформативнее

Если я по каждому чиху буду так делать, заводить локальные переменные для промежуточных переменных, то строк будет не много, а очень много. Я и так уже боюсь представить какими словами будет ругаться DC, когда узнает сколько их.

Извините но когда меня критикуют, я предпочитаю больше конкретики. что, где, почему.

Изменено 14 Февраля 2015 пользователем Zander_driver

[Desertir 202]

@xStream, это про чей пост, мой?

Это счетчик цикла, если что.

Для рядового скриптера буковка А будет означать все что угодно. А например "index" или хотя бы "id" уже что-то.

будет ругаться DC

Я так посмотрю тебе важно мнение только одного человека.

Для таблиц можно и in pairs использовать. И это не было критикой, я написал, как сделал бы я, код становится более легкочитаемым + вдруг я захочу использовать эту переменную снова в цикле, опять придется писать self.data[a] + если я чтото изменю надо будет это исправлять во всех местах, да и вообще дублирование кода моветон.

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

Добавилось конкретики?

Изменено 14 Февраля 2015 пользователем Desertir

[Zander_driver 10 166]

 

 

Я так посмотрю тебе важно мнение только одного человека.

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

В остальном я почти привык к тому что все что я делаю почти никому не нужно.

 

 

Добавилось конкретики?

Вообще я xStream имел в виду. Чем ей не понравился мой предыдущий пост - для меня загадка.

[TIGER_VLAD 361]

Всем привет. У меня такие вопросы: 1.Насколько вредно для движка использовать(выдавать актору/забирать) например 10-20 инфопорций каждые 5 минут? Движок выдержит? 

2. Какие есть аналоги инфопорций , или как можна их имитировать? Заранее спасибо.

[Andrey07071977 18]

Привет TIGER VLAD,

 

1. Выдержит

2. На сталкерин вики есть статья про альтернативу, почитай, не знаю насколько она актуальна

[UnLoaded 313]

 

 

1.Насколько вредно для движка использовать(выдавать актору/забирать) например 10-20 инфопорций каждые 5 минут? Движок выдержит?  2. Какие есть аналоги инфопорций , или как можна их имитировать? Заранее спасибо.

Попытаюсь задать тебе вопрос чуток с другой позиции: а может тебе стоит рассказать участникам форума, какова цель выдавать\забирать 10-20 и-п каждые 5 мин. Т.е. когда присутствующие поймут цель этого действа - возможно они смогут предложить тебе более правильную альтернативу? Как ты думаешь?

[Malandrinus 611]

@TIGER_VLAD,Смотря зачем надо. На событие выдачи инфопорции в современных модах навешано куча кода (о котором даже и не знаешь), поэтому лучше избегать использования инфопорций, если в них нет реальной нужды. Нужда есть, если инфопорции используются по прямому назначению - для сюжетных целей, или если их выдаёт/забирает движок. Почти во всех остальных случаях можно заменить инфопорции обычными переменными, глобальными или локальными по ситуации. Собственно, если рассмотреть инфопорцию отстранённо, то это не что иное, как специфическая переменная с типом bool. Инфопорция однако - это сохраняемая переменная. Если нужно значение сохранять, то можно использовать системы хранения, коих уже немало (хотя бы АМК).

[TIGER_VLAD 361]

@Malandrinus, Понял, спасибо. А как например сохранять переменную в se_stor.script от Artos`a . Есть фунции set(запись) и get(чтение), не пойму где нужно вызывать se_stor.get(var_name, default) . И правильно ли использовать в этом случае se_stor ?

[UnLoaded 313]

 

 

Инфо-порция однако - это сохраняемая переменная. Если нужно значение сохранять, то можно использовать системы хранения, коих уже немало (хотя бы АМК).

Хм, а с каких это пор уже требуется самостоятельно сохранять "выданные"(активные) инфо-порции ? Движок уже этим не занимается ?

 

 

 

И правильно ли использовать в этом случае se_stor ?

Зачем, если "выданную"(активную) и-п движок сохранит сам и однозначно ?

 

Или я отстал от жизни и уже чего-то не понимаю в современной системе обработки и-п ?

[TIGER_VLAD 361]

@UnLoaded, Ты немного неправильно понял . Мы говорим о аналоге инфопорций - логических переменных , которые нужно сохранять .

 

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

Изменено 20 Февраля 2015 пользователем TIGER_VLAD