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

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

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

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

а хотя...

а хотя...

Есть еще разные типы брони

И разные дополнения

ну вот я тоже об этом подумал.... подумать надо

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

короч подожду человека уже

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

я вообще не про такие геттеры говорил если что

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

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

а про какие?

а про какие?

просто геттер прайват поля

ну так я про них и говорю

зачем они нужны?

вот прям для всех полей

ну так я про них и говорю

А чем он здесь плох?

ну так урон же не у пушки, а у всего перса с одетой пушкой

Если считать будет не топор, то геттер как бы маст хев

короче смотря как делать

тоже можно по разному

у меня только одна пушка единовременно одета может быть

при одевании идет пересчет характеристик от всего шмота

что бы кучу раз не пересчитывать при нанесении урона, это же не синглплеер на компе

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

ну так урон же не у пушки, а у всего перса с одетой пушкой

конечно, ну вот ссмотри, как я это вижу. Только можно не про пушки а ппро топоры? мне как то ближе. Ну вот есть перс у него есть свои хаарактеристики влияющие на урон, скажем если он из расы орков то урон увеличивается на 10%, Есть у него топор, у топораа есть свои характерисстики, например минимальный максимальный урон, шанс критаа величина крита и тд. Ты дергаешь метод перса который считает урон, внутри перса дергается метод топора который считает урон топора уже с учетом всех модификаторов, потому что как по мне знать снаружи о нихз не наадо, А уже к полученному значению сам перс применяет свои модификаторы и возвращает финаальное значение

конечно, ну вот ссмотри, как я это вижу. Только можно не про пушки а ппро топоры? мне как то ближе. Ну вот есть перс у него есть свои хаарактеристики влияющие на урон, скажем если он из расы орков то урон увеличивается на 10%, Есть у него топор, у топораа есть свои характерисстики, например минимальный максимальный урон, шанс критаа величина крита и тд. Ты дергаешь метод перса который считает урон, внутри перса дергается метод топора который считает урон топора уже с учетом всех модификаторов, потому что как по мне знать снаружи о нихз не наадо, А уже к полученному значению сам перс применяет свои модификаторы и возвращает финаальное значение

не так

почему?

при ситуации когда надо "перерасчитывать при надевании" не меняется вообще ничего

ну охеренно, пришел наакинул наа вентилятор, а потом "я игнорю сообщения"....

=)

Если считать будет не топор, то геттер как бы маст хев

а действительно нужно считать в одном месте? нельзя калькуляцию разбить на части и считать каждую часть там где есть все необходимые данные?

и что это будет не какой то редкий специфический кейс,

ну вооооот, все свалили =((((

и что это будет не какой то редкий специфический кейс,

Я ж не говорил, что должно быть все в одном месте ?

Каждое оружие для себя будет считать

так а почему тогда "гетеры маст хэв"?

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

с учетом характеристик персов, показаателей брони и тд?

так а почему тогда "гетеры маст хэв"?

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

Нужно ведь как-то узнать что за тип у него

с учетом характеристик персов, показаателей брони и тд?

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

а ну да. вроде спорить не о чем =)

Угу

ну охеренно, пришел наакинул наа вентилятор, а потом "я игнорю сообщения"....

он же сказал что "пока не подойдет к компу", успокойся уже

я спокоен

Неа

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

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

?

ты про какую - ссылку на вики где ссылки на нормальные публикации?

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

message passing and actor model

как-то так

> потому-что объяснить толково некому. как-будто никто не знает. мне казалось что метафора комьютерной сети должна объяснить суть....

ну то есть... идея то простая

все, я тут, щя напишу 10 мин

акторы логику содержат?

акторы логику содержат?

конечно

и передаются по сети?

мм.... экторы не передаются по сети, они - ноды сети

по "сети" этой передаются сообщения

эктор = комьютер в сети, грубо говоря

сеть тут - абстрактная штука, а не что-то из разряда OSI. Это как процессы и пайпы в unix

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

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

что значит "обычное программирование"

ну вот смотри

основное отличие

если мы возьмем тот же C++ или Java

и представим себе объект (инстанс класса) как эктор

то которое бы я реализовывал без библиотек

то которое бы я реализовывал без библиотек

так

что бы было проще представь себе 2 эктора как 2 инстанса класса в C++ или джаве. Что бы понимать основную разницу - сделаем так что каждый из этих экторов делят рантайм между собой. Например - они могут крутиться в разных тредах что позволяет им работать одновременно.

а тот факт что очередь там для параллельного програмирования, то отбросив ее, точно будет обычное программирование

а тот факт что очередь там для параллельного програмирования, то отбросив ее, точно будет обычное программирование

но суть actor model именно в том как разруливать конкурентный доступ к ресурсам

так что если ты это выкидываешь - то у тебя не actor model)

я не пишу такое сложное, пока

то есть у тебя нет приложений с локами?

у меня пока rx

хз что для тебя rx..... для меня это просто удобный способ работы с событиями

вся суть идеи экторов может быть выражена следующими пунктами: - отправителю нет дела кто будет обрабатывать сообщение (late binding по сути) - получатель сообщения обработает его когда будет свободен, то есть рантайм должен предоставлять некую очередь для каждого эктора, мэйлбоксы

то есть на выходе мы имеем сэт примитивов

на которых ты можешь строить как прикольные асинхронные штуки построенные на pub/sub так и классические системы к которым ты привык в шарпах, джаве, плюсах или что ты там делаешь, с синхронными сообщениями и т.д.

ну и нюанс - все это дает тебе возможность подменять части приложения в рантайме

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

языки типа C++/Java/C# предоставляют тебе лишь малую часть возможностей которые дает этот подход

потому придумывают всякие там akka что бы сверху нафигачить эти примитивы и естественно это будет менее эффективно нежели в вариантах где виртуальная машина сама предусматривает подобный ход дел

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

rx не просто события

rx не просто события

ой маленькая идея этот ваш rx... я бы может чего и мог сказать на тему унификации интерфейсов, монад, функциональщины и т.д. но я не настолько сведущ. Это вон к @mkusher

а меня ФП все еще пугает

хотя я и понимаю что интересного там очень много

я его как фп не рассматриваю даже

Я офтопа накину малеха @fes0r показать что такое боль? (нет) ?

https://www.reddit.com/r/programming/comments/21te31/the_actor_model_in_php/

очень мощная библиотека для асинхрона

https://www.reddit.com/r/programming/comments/21te31/the_actor_model_in_php/

я с @zloyuser обсуждал идею чуть по другому реализовать

я с @zloyuser обсуждал идею чуть по другому реализовать

Еслии не секрет - в чем фича?

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

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

интригуешь)

да просто щя будет зарево