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

V>Я тебе дал вполне конкретное представление о том, что есть IDL, не наговаривай на конкретно CORBA или COM.
V>В этом месте тебе должно быть уже понятно отличие Google protobuf или Microsoft bond от фреймворков подобного рода.

Та же википедия (и огромное количество других ресурсов) называет язык protobuf IDL. Официальная документация — нет, но к примеру Apache Thrift (полный аналог protobuf) в документации называет свой язык IDL. Дальнейший спор о терминах мне неинтересен.

V>Потому что в первом случае ты сам работаешь напрямую с транспортным слоем, а во втором тебе транспортный слой, считай, не видим

То, что ты называешь транспортным слоем, в моем случае, считай, не видимо. Пользователь работает с сервисами через функции, возврат значений (если есть) и проброска исключений — под капотом.

V>Не надо путать фреймворки сугубо для бинарной сериализации и фреймворки для удалённых вызовов методов объектов.

И protobuf, и Thrift, и мой фреймворк поддерживают описание сервисов и RPC.

V>Почему именно он — он лучший на сегодня из всех.
V>Хотя, даже сам ASN.1 весьма удобен

Я не разделяю твою точку зрения об удобстве языка ASN.1, так как использовал и ASN.1 и альтернативы.

V>Например, в этом языке есть ЯВНАЯ поддержка optional-семантики.
V>А еще в языке есть параметрические типы. ))

Это есть и в моем языке.

_>>При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет.
V>Вот тебе с метаинформацией для C#:

	Скрытый текст
	V> V>[ASN1Sequence ( Name = "TestSequence", IsSet = false )] V>public class TestSequence V>{ V> private long field1_ ; V> [ASN1Element ( Name = "field1", IsOptional = false , HasTag = false , HasDefaultValue = false ) ] V> public long Field1 { V> get { return field1_; } V> set { field1_ = value; } V> } V>... V>

Речь шла о метаданных в DSL, определяющих генерируемый код, а не о метаданных в генерируемом коде. Зачем мне C# атрибуты, когда я могу сгенерировать все что захочу?

V>А не путаете ли вы, батенька, транспортный слой с прикладным?
V>Или у тебя там всё вперемешку?

Я объяснял, что в IDL/DSL/whatever определяю модель дизайн-данных, и почему мне это необходимо.

V>Блин, во всех этих сетевых делах ничего изобретать не надо — всё уже изобретено до нас. Например, любые обращения к серверу БД — это точно такое же обращение к сетевому внешнему сервису. И точно так же существует некий слой DAL, дальше которого сугубо транспортные типы данных не пролезают.

1) У меня на это нет ни процессорного времени, ни возможности делать лишние аллокации. Мне нужен максимальный FPS.
2) Маппинг транспортных типов на модельные все равно пришлось бы генерировать. Так зачем это надо? Обычно у меня минимум типов, которые используются исключительно как транспортные — в этом нет необходимости, так как сервисные функции принимают и возвращают произвольное количество аргументов. Редкое исключение — дельта-рекорды, о которых я писал.
3) Игры не похожи на бизнес-приложения. Не все практики одинаково полезны для них.

V>Потому что ты уткнулся в архитектуру без DAL.

Я никуда не уткнулся, потому что я не использую ASN.1.

V>Я тебе предлагал на основе BLToolkit сделать автоматический маппинг с транспортного слоя на прикладной.

1) На большинстве таргет-платформ запрещен JIT. Подозреваю, что для BLToolkit это будет проблемой.
2) Все, чем мне может помочь BLToolkit, я могу сгенерировать. Мне кажется, ты недооцениваешь простоту использования расширяемого кодогенератора, возможно, у тебя никогда не было подходящего инструмента.
3) Я еще тогда объяснил, почему конкретно в случае дельта-рекордов обновление ручное. Потому что: первое — при обновлении коллекций настолько много вариантов, что вручную написать проще, чем определять атрибутами (неважно, в коде C# или DSL). Второе — не всегда есть явное соответствие полей апдейта и сущности.
4) Проблемы, которую ты предлагаешь решать, не существует.

V>А еще потому, что ASN.1 предлагает тебе trade-off изкаробки: можно выбирать из целой градации профилей кодирования, от самых эффективных по размеру пакета до самых эффективных по затрачиваемым ресурсам проца. И тебе несложно будет переключать эти профили. Например, если у какого-то клиента плохой пинг, то серверу стоит ужать трафик в сторону такого клиента в НЕСКОЛЬКО РАЗ. А если хороший, то стоит тратить на такого клиента меньше тиков процессора.

Для игр это совершенно бессмысленно. Плохой пинг не станет лучше, если вместо 40 байт послать 20.

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

За 8 лет использования конкретно этого IDL у нас был только один баг, связанный со сгенерированным кодом сериализации (я не считаю баги, в которых сгенерированный код не компилировался — эти ловятся элементарно, хотя и тоже редкость), и он был быстро выявлен и пофикшен. Так что мой опыт вкорне отличается от твоего, а своему я доверяю больше.

V>Ты, таки, взял бы в руки ANTLR. Это мощнейшая визуальная система разработки и отладки грамматик.

Я брал. Спасибо, не надо. А в наше время я возьму Нитру. Но я не хочу и не буду об этом спорить.

V>В ANTLR ты можешь вести быструю разработку языка, вводить новые конструкции в него и достоверно на каждом шаге знать — получается ли у тебя язык однозначным на любых входных цепочках или уже нет. В случае PEG ты об этом не узнаешь до тех пор, пока тебе на входе не встретится такая цепочка. И вот ты создашь в JIRA тикет, вынужден будешь открыть исходник своего парсера и начать медитировать.

PEG использовал часто. Таких проблем не встречал.

_>>а удобная интерполяция строк как в Nemerle это musthave для кодогенерации.
V>Да это вообще для кодогенерации пофиг. Экономия 1% усилий.

Я не согласен. Это очень большое подспорье. Код нашего кодогенератора (кроме таргет-назависимого ядра) состоит из интерполяции строк процентов на 80, если не больше.