D
ну вообще, если убрать класс ForwardedMessage и в конце prepareMessage сделать чек на форвард, будет гораздо меньше проблем
Size: a a a
2017 November 01
s
если не удалять поле, будет бесконечная рекурсия, скорее всего
ты фиксишь код даже не проверив будет или нет? =_=
D
ты фиксишь код даже не проверив будет или нет? =_=
в смысле?
s
ну вообще, если убрать класс ForwardedMessage и в конце prepareMessage сделать чек на форвард, будет гораздо меньше проблем
тип сам позволяет себя чекнуть
s
в смысле?
ну ты говоришь наверное там будет рекурсия. А может и не будет
s
зачем что-то чинить если не проверил наверняка что там точно есть проблема
D
ладно, сейчас проверю будет ли рекурсия
D
зачем что-то чинить если не проверил наверняка что там точно есть проблема
D
да, она есть
s
То не проще ли правильно описать выход из рекурсии чем над данными издеваться
Dv
@fvnever ты про монструозность кода или про стикеры
[Sticker 🤘] ?Я говорил про
delete.Dv
Или можно перенести этот
delete msg.forwarded_mesage из toString в getDetailsА нельзя его просто выпилить? Зачем там вообще делит?
D
Dv
В
toString?D
В
toString?toString вызывает prepareMessage.
D
prepareMessage вызывает toString.
Dv
А
prepareMessage вызывает toString при наличии этого флага?D
Да.
Dv
Ну ок, давайте сделаем вариант
prepareMessage, который принимает флаг снаружи.Dv
В обычном случае будем передавать туда флаг из объекта, а в
toString будем передавать всегда false.