Здравствуйте, Pauel, Вы писали:

P>·>Ты заявил, что там по ссылке какой-то "правильный" ответ, не совпадающий с моей цитатой. И ты так трудишься, скрывая свой ответ, что у меня стойкое впечатление, что ты что-то не так понял; вместо того, что просто признать ошибку, разводишь демагогию на пустом месте.
P>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся.
Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких. Как выяснилось в плюсах такой дыры нет, ты ошибся. В шарпе такой дыры тоже нет, там требуются явное приведение типов. В джаве только если использовать legacy raw types и игнорировать предупреждения компилятора. Какие ещё "почти все" мейнстрим языки остались?

P>>>То есть, всё тот же кейс "заведомо некорректный код скомпилировался т.к. система типов не смогла защитить"
P>·>Это не дыра, т.к. потребуется явное преобразование типа. А там где оно есть, там, очевидно, может вылетать Class Cast Exception. В случае же ts там тупо молча без явных конструкций можно менять read-only поля и ловить CCE (ну точнее null reference exception, т.к. duck typing) в случайных строчках кода, happy debugging.
P>Это не такая страшная помеха, как ты представляешь. Есть куча других методов ограничить доступ чтением.
Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали.

P>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая.
Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте. Почти из той же оперы, что и расстрел памяти.

P>·>Так почему твой сериализатор быстрее?
P>Рефлексия дешовая.
Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript?
Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт.

P>·>Скажем, из бенчмарков о структуре в памяти подходит вот этот бенч. И нода совсем не блещет, на уровне php.
P>Ты бы хоть посмотре, что там:
P>Мне не сильно понятно, начорта там воркертреды
Ну ты сам эти бенчмарки притащил. И сказал, что хорошие бенчмарки, и выводов из них понаделал.

Здравствуйте, Pauel, Вы писали:

P>·>Ты заявил, что там по ссылке какой-то "правильный" ответ, не совпадающий с моей цитатой. И ты так трудишься, скрывая свой ответ, что у меня стойкое впечатление, что ты что-то не так понял; вместо того, что просто признать ошибку, разводишь демагогию на пустом месте.
P>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся.
Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких. Как выяснилось в плюсах такой дыры нет, ты ошибся. В шарпе такой дыры тоже нет, там требуются явное приведение типов. В джаве только если использовать legacy raw types и игнорировать предупреждения компилятора. Какие ещё "почти все" мейнстрим языки остались?

P>>>То есть, всё тот же кейс "заведомо некорректный код скомпилировался т.к. система типов не смогла защитить"
P>·>Это не дыра, т.к. потребуется явное преобразование типа. А там где оно есть, там, очевидно, может вылетать Class Cast Exception. В случае же ts там тупо молча без явных конструкций можно менять read-only поля и ловить CCE (ну точнее null reference exception, т.к. duck typing) в случайных строчках кода, happy debugging.
P>Это не такая страшная помеха, как ты представляешь. Есть куча других методов ограничить доступ чтением.
Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали.

P>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая.
Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте. Почти из той же оперы, что и расстрел памяти.

P>·>Так почему твой сериализатор быстрее?
P>Рефлексия дешовая.
Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript?
Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт.

P>·>Скажем, из бенчмарков о структуре в памяти подходит вот этот бенч. И нода совсем не блещет, на уровне php.
P>Ты бы хоть посмотре, что там:
P>Мне не сильно понятно, начорта там воркертреды
Ну ты сам эти бенчмарки притащил. И сказал, что хорошие бенчмарки, и выводов из них понаделал.

заметь вот это: тут ворктредов нет, и оно вообще жуть тормозит по всем параметрам.