Сообщение Re[10]: Опциональные типы от 25.02.2017 10:31
Изменено 25.02.2017 10:35 vdimas
Re[10]: Опциональные типы
Здравствуйте, meadow_meal, Вы писали:
_>Ты понятие IDL трактуешь очень узко, IDL это не только CORBA и COM.
Я тебе дал вполне конкретное представление о том, что есть IDL, не наговаривай на конкретно CORBA или COM.
Почитай про тот же ICE:
https://en.wikipedia.org/wiki/Internet_Communications_Engine
В этом месте тебе должно быть уже понятно отличие Google protobuf или Microsoft bond от фреймворков подобного рода.
Не надо путать фреймворки сугубо для бинарной сериализации и фреймворки для удалённых вызовов методов объектов.
Потому что в первом случае ты сам работаешь напрямую с транспортным слоем, а во втором тебе транспортный слой, считай, не видим ("прозрачен", согласен IT-терминологии).
Поэтому, коль я по косвенным признакам догадался о неверном использовании тобой абревиатуры IDL, я предложил тебе фреймворк другого типа — ASN.1.
Почему именно он — он лучший на сегодня из всех.
Даже если тебе не нравится сам ASN.1 — я уже сказал что надо делать — надо просто написать свой примитивнейший DSL, который на выходе даст ASN.1.
Хотя, даже сам ASN.1 весьма удобен, просто надо потратить хотя бы час-другой времени на его изучение. Например, в этом языке есть ЯВНАЯ поддержка optional-семантики.
А еще в языке есть параметрические типы. ))
Т.е. можно задать генерик-описание сообщение, например:
Зависимости можно протягивать:
а потом специализировать
А еще для этих параметрических типов можно описывать классы типов:
И вот для разных уровней могут быть разные кодировки сообщений в потоке, потому что битовая ширина x и y может быть разной.
Есть еще много других прикольных плюшек, чего стоит один только тип SET — это же бомба!
Кароч, я много одно время смотрел альтернативных технологий, но они по выразительности и мощи проигрывают ASN.1, как первоклашки проигрывают профессору ВУЗ-а в области математики. ))
_>Я на это тоже уже отвечал. ASN.1 compiler генерирует то, что генерирует, а не то, что мне нужно.
У некоторых компилятором маппинг можно настраивать.
_>При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет.
Опять же — есть:
http://bnotes.sourceforge.net/
Вот тебе с метаинформацией для C#:
_>То есть в Эрланге тупл вместо рекорда — нельзя, typespec — нельзя, в C# struct вместо class — нельзя, использовать алиас на существующий тип данных указав для него внешний сериализатор — нельзя, сгенерировать Equals/EqualityComparer/или что еще в голову взбредет — нельзя.
Здра моя ра!
А не путаете ли вы, батенька, транспортный слой с прикладным?
Или у тебя там всё вперемешку?
Блин, во всех этих сетевых делах ничего изобретать не надо — всё уже изобретено до нас. Например, любые обращения к серверу БД — это точно такое же обращение к сетевому внешнему сервису. И точно так же существует некий слой DAL, дальше которого сугубо транспортные типы данных не пролезают.
_>Если и ошибся в каких деталях, все равно рано или поздно уткнусь в ограничения.
Потому что ты уткнулся в архитектуру без DAL.
_>То есть используя ASN.1 как таргет-язык для генерации, я просто не могу решать те задачи, которые ставлю перед исходным DSL.
ASN.1 тут не при чем от слова совсем, хосподя...
Я тебе предлагал на основе BLToolkit сделать автоматический маппинг с транспортного слоя на прикладной.
Я же говорю — ты не понял НИ СЛОВА из того, что я писал тебе ранее.
Даже где-то обидно... ))
_>Но главное даже не это. Даже если б это было возможно, но — нахрена? Я бы понял, если б ты предложил ASN.1 или что еще как основной язык (но в случае с ASN.1 это полное безумие), но как промежуточный?
Потому что эффективная и надежная сериализация. Т.е. чтобы не тратить квантов внимания на эту область, в которой в случае ручной её реализации постоянно возникают ошибки и вообще оно происходит зачастую неэффекктивно.
А еще потому, что ASN.1 предлагает тебе trade-off изкаробки: можно выбирать из целой градации профилей кодирования, от самых эффективных по размеру пакета до самых эффективных по затрачиваемым ресурсам проца. И тебе несложно будет переключать эти профили. Например, если у какого-то клиента плохой пинг, то серверу стоит ужать трафик в сторону такого клиента в НЕСКОЛЬКО РАЗ. А если хороший, то стоит тратить на такого клиента меньше тиков процессора.
Никакая другая технология вот всеми этими совокупными св-вами НЕ обладает. Более того. На сегодня идёт развитие в нужном направлении только ASN.1.
Остальные конкурирующие технологии мертвы — будучи разработаны однажды для чего-то быстро становятся невостребованы по окончании проекта, в котором были применены. Эдакая "одноразовость", мертвечинка...
_>Но я не понимаю, в чем именно ты видишь проблему генерации кода сериализации. В самой кодогенерации или в оптимальности сгенерированного кода?
И там и там.
А еще в ошибках, т.е. тупо в багах. Был я как-то на одном проекте, так только в коде бинарной кастомной сериализации отловил порядка десятка ошибок. Причем, ошибки удачно максировались тем, что периодически шла не только дельта, но и абсолютные значения, угу. Поэтому ошибки в дельтах приводили лишь к "кратковременному вранью", которое списывали на притормаживание. )) А не было никакого притормаживания, были баги.
V>>Потому что удобных инструментов для разработки своих языков полно.
_>Разве с этим кто-то спорит?
V>>ANTLR
_>Ну и что ANTLR-то? Nemerle.Peg не сложнее
Он не не сложнее, а беднее на многие-многие порядки. Он пуст как абстрактное zero. Как Мухосранк посреди Сибири. ))
Ты, таки, взял бы в руки ANTLR. Это мощнейшая визуальная система разработки и отладки грамматик.
В принципе, ПОСЛЕ отладки грамматики в ANTLR запросто можно закодировать её в чем угодно, хоть даже в Nemerle.
В ANTLR ты можешь вести быструю разработку языка, вводить новые конструкции в него и достоверно на каждом шаге знать — получается ли у тебя язык однозначным на любых входных цепочка или уже нет. В случае PEG ты об этом не узнаешь до тех пор, пока тебе на входе не встретится такая цепочка. И вот ты создашь в JIRA тикет, вынужден будешь открыть исходник своего парсера и начать медитировать.
_>а удобная интерполяция строк как в Nemerle это musthave для кодогенерации.
Да это вообще для кодогенерации пофиг. Экономия 1% усилий. Проблема чаще не в кодогенерации, а в модели, по которой она происходит. А модель зависит от языка. А вот разработать сам язык — это и есть самая мякотка.
_>Прочитал, но не понял, на что ты обиделся.
Я не принимаю простых "я не согласен", "тут не прав", "а это грязных хак" (чего???) и прочей такой фигни.
Технический спор это:
— вот тут ты не прав, потому что: ...
или
— а здесь я бы предложил альтернативу, которая в сравнении с исходным вариантом даёт следующее: ...
И т.д. в этом же духе.
Всё остальное — это просто обмен какашками, в какую бы вежливую форму они ни были завёрнуты.
_>Ты понятие IDL трактуешь очень узко, IDL это не только CORBA и COM.
Я тебе дал вполне конкретное представление о том, что есть IDL, не наговаривай на конкретно CORBA или COM.
Почитай про тот же ICE:
https://en.wikipedia.org/wiki/Internet_Communications_Engine
В этом месте тебе должно быть уже понятно отличие Google protobuf или Microsoft bond от фреймворков подобного рода.
Не надо путать фреймворки сугубо для бинарной сериализации и фреймворки для удалённых вызовов методов объектов.
Потому что в первом случае ты сам работаешь напрямую с транспортным слоем, а во втором тебе транспортный слой, считай, не видим ("прозрачен", согласен IT-терминологии).
Поэтому, коль я по косвенным признакам догадался о неверном использовании тобой абревиатуры IDL, я предложил тебе фреймворк другого типа — ASN.1.
Почему именно он — он лучший на сегодня из всех.
Даже если тебе не нравится сам ASN.1 — я уже сказал что надо делать — надо просто написать свой примитивнейший DSL, который на выходе даст ASN.1.
Хотя, даже сам ASN.1 весьма удобен, просто надо потратить хотя бы час-другой времени на его изучение. Например, в этом языке есть ЯВНАЯ поддержка optional-семантики.
А еще в языке есть параметрические типы. ))
Т.е. можно задать генерик-описание сообщение, например:
Point{DataType} ::= SEQUENCE {
x DataType,
y DataType
}Зависимости можно протягивать:
Move{DataType} ::= SEQUENCE {
from Point{DataType},
to Point{DataType}
}а потом специализировать
UpdateXXX ::= CHOICE {
i [0] Move<int32>,
f [1] Move<float>,
d [2] Move<double>
}А еще для этих параметрических типов можно описывать классы типов:
LevelParams ::= CLASS {
&level-field-width int32,
&level-field-height int32,
}
Move-PDU{LevelParams : param} ::= SEQUENCE {
x INTEGER (0..param.&level-field-width),
y INTEGER (0..param.&level-field-height)
}И вот для разных уровней могут быть разные кодировки сообщений в потоке, потому что битовая ширина x и y может быть разной.
Есть еще много других прикольных плюшек, чего стоит один только тип SET — это же бомба!
Кароч, я много одно время смотрел альтернативных технологий, но они по выразительности и мощи проигрывают ASN.1, как первоклашки проигрывают профессору ВУЗ-а в области математики. ))
_>Я на это тоже уже отвечал. ASN.1 compiler генерирует то, что генерирует, а не то, что мне нужно.
У некоторых компилятором маппинг можно настраивать.
_>При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет.
Опять же — есть:
http://bnotes.sourceforge.net/
Вот тебе с метаинформацией для C#:
[ASN1Sequence ( Name = "TestSequence", IsSet = false )]
public class TestSequence
{
private long field1_ ;
[ASN1Element ( Name = "field1", IsOptional = false , HasTag = false , HasDefaultValue = false ) ]
public long Field1 {
get { return field1_; }
set { field1_ = value; }
}
..._>То есть в Эрланге тупл вместо рекорда — нельзя, typespec — нельзя, в C# struct вместо class — нельзя, использовать алиас на существующий тип данных указав для него внешний сериализатор — нельзя, сгенерировать Equals/EqualityComparer/или что еще в голову взбредет — нельзя.
Здра моя ра!
А не путаете ли вы, батенька, транспортный слой с прикладным?
Или у тебя там всё вперемешку?
Блин, во всех этих сетевых делах ничего изобретать не надо — всё уже изобретено до нас. Например, любые обращения к серверу БД — это точно такое же обращение к сетевому внешнему сервису. И точно так же существует некий слой DAL, дальше которого сугубо транспортные типы данных не пролезают.
_>Если и ошибся в каких деталях, все равно рано или поздно уткнусь в ограничения.
Потому что ты уткнулся в архитектуру без DAL.
_>То есть используя ASN.1 как таргет-язык для генерации, я просто не могу решать те задачи, которые ставлю перед исходным DSL.
ASN.1 тут не при чем от слова совсем, хосподя...
Я тебе предлагал на основе BLToolkit сделать автоматический маппинг с транспортного слоя на прикладной.
Я же говорю — ты не понял НИ СЛОВА из того, что я писал тебе ранее.
Даже где-то обидно... ))
_>Но главное даже не это. Даже если б это было возможно, но — нахрена? Я бы понял, если б ты предложил ASN.1 или что еще как основной язык (но в случае с ASN.1 это полное безумие), но как промежуточный?
Потому что эффективная и надежная сериализация. Т.е. чтобы не тратить квантов внимания на эту область, в которой в случае ручной её реализации постоянно возникают ошибки и вообще оно происходит зачастую неэффекктивно.
А еще потому, что ASN.1 предлагает тебе trade-off изкаробки: можно выбирать из целой градации профилей кодирования, от самых эффективных по размеру пакета до самых эффективных по затрачиваемым ресурсам проца. И тебе несложно будет переключать эти профили. Например, если у какого-то клиента плохой пинг, то серверу стоит ужать трафик в сторону такого клиента в НЕСКОЛЬКО РАЗ. А если хороший, то стоит тратить на такого клиента меньше тиков процессора.
Никакая другая технология вот всеми этими совокупными св-вами НЕ обладает. Более того. На сегодня идёт развитие в нужном направлении только ASN.1.
Остальные конкурирующие технологии мертвы — будучи разработаны однажды для чего-то быстро становятся невостребованы по окончании проекта, в котором были применены. Эдакая "одноразовость", мертвечинка...
_>Но я не понимаю, в чем именно ты видишь проблему генерации кода сериализации. В самой кодогенерации или в оптимальности сгенерированного кода?
И там и там.
А еще в ошибках, т.е. тупо в багах. Был я как-то на одном проекте, так только в коде бинарной кастомной сериализации отловил порядка десятка ошибок. Причем, ошибки удачно максировались тем, что периодически шла не только дельта, но и абсолютные значения, угу. Поэтому ошибки в дельтах приводили лишь к "кратковременному вранью", которое списывали на притормаживание. )) А не было никакого притормаживания, были баги.
V>>Потому что удобных инструментов для разработки своих языков полно.
_>Разве с этим кто-то спорит?
V>>ANTLR
_>Ну и что ANTLR-то? Nemerle.Peg не сложнее
Он не не сложнее, а беднее на многие-многие порядки. Он пуст как абстрактное zero. Как Мухосранк посреди Сибири. ))
Ты, таки, взял бы в руки ANTLR. Это мощнейшая визуальная система разработки и отладки грамматик.
В принципе, ПОСЛЕ отладки грамматики в ANTLR запросто можно закодировать её в чем угодно, хоть даже в Nemerle.
В ANTLR ты можешь вести быструю разработку языка, вводить новые конструкции в него и достоверно на каждом шаге знать — получается ли у тебя язык однозначным на любых входных цепочка или уже нет. В случае PEG ты об этом не узнаешь до тех пор, пока тебе на входе не встретится такая цепочка. И вот ты создашь в JIRA тикет, вынужден будешь открыть исходник своего парсера и начать медитировать.
_>а удобная интерполяция строк как в Nemerle это musthave для кодогенерации.
Да это вообще для кодогенерации пофиг. Экономия 1% усилий. Проблема чаще не в кодогенерации, а в модели, по которой она происходит. А модель зависит от языка. А вот разработать сам язык — это и есть самая мякотка.
_>Прочитал, но не понял, на что ты обиделся.
Я не принимаю простых "я не согласен", "тут не прав", "а это грязных хак" (чего???) и прочей такой фигни.
Технический спор это:
— вот тут ты не прав, потому что: ...
или
— а здесь я бы предложил альтернативу, которая в сравнении с исходным вариантом даёт следующее: ...
И т.д. в этом же духе.
Всё остальное — это просто обмен какашками, в какую бы вежливую форму они ни были завёрнуты.
Re[10]: Опциональные типы
Здравствуйте, meadow_meal, Вы писали:
_>Ты понятие IDL трактуешь очень узко, IDL это не только CORBA и COM.
Я тебе дал вполне конкретное представление о том, что есть IDL, не наговаривай на конкретно CORBA или COM.
Почитай про тот же ICE:
https://en.wikipedia.org/wiki/Internet_Communications_Engine
В этом месте тебе должно быть уже понятно отличие Google protobuf или Microsoft bond от фреймворков подобного рода.
Не надо путать фреймворки сугубо для бинарной сериализации и фреймворки для удалённых вызовов методов объектов.
Потому что в первом случае ты сам работаешь напрямую с транспортным слоем, а во втором тебе транспортный слой, считай, не видим ("прозрачен", согласен IT-терминологии).
Поэтому, коль я по косвенным признакам догадался о неверном использовании тобой абревиатуры IDL, я предложил тебе фреймворк другого типа — ASN.1.
Почему именно он — он лучший на сегодня из всех.
Даже если тебе не нравится сам ASN.1 — я уже сказал что надо делать — надо просто написать свой примитивнейший DSL, который на выходе даст ASN.1.
Хотя, даже сам ASN.1 весьма удобен, просто надо потратить хотя бы час-другой времени на его изучение. Например, в этом языке есть ЯВНАЯ поддержка optional-семантики.
А еще в языке есть параметрические типы. ))
Т.е. можно задать генерик-описание сообщения, например:
Зависимости можно протягивать:
а потом специализировать
А еще для этих параметрических типов можно описывать классы типов:
И вот для разных уровней могут быть разные кодировки сообщений в потоке, потому что битовая ширина x и y может быть разной.
Есть еще много других прикольных плюшек, чего стоит один только тип SET — это же бомба!
Кароч, я много одно время смотрел альтернативных технологий, но они по выразительности и мощи проигрывают ASN.1, как первоклашки проигрывают профессору ВУЗ-а в области математики. ))
_>Я на это тоже уже отвечал. ASN.1 compiler генерирует то, что генерирует, а не то, что мне нужно.
У некоторых компилятором маппинг можно настраивать.
_>При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет.
Опять же — есть:
http://bnotes.sourceforge.net/
Вот тебе с метаинформацией для C#:
_>То есть в Эрланге тупл вместо рекорда — нельзя, typespec — нельзя, в C# struct вместо class — нельзя, использовать алиас на существующий тип данных указав для него внешний сериализатор — нельзя, сгенерировать Equals/EqualityComparer/или что еще в голову взбредет — нельзя.
Здра моя ра!
А не путаете ли вы, батенька, транспортный слой с прикладным?
Или у тебя там всё вперемешку?
Блин, во всех этих сетевых делах ничего изобретать не надо — всё уже изобретено до нас. Например, любые обращения к серверу БД — это точно такое же обращение к сетевому внешнему сервису. И точно так же существует некий слой DAL, дальше которого сугубо транспортные типы данных не пролезают.
_>Если и ошибся в каких деталях, все равно рано или поздно уткнусь в ограничения.
Потому что ты уткнулся в архитектуру без DAL.
_>То есть используя ASN.1 как таргет-язык для генерации, я просто не могу решать те задачи, которые ставлю перед исходным DSL.
ASN.1 тут не при чем от слова совсем, хосподя...
Я тебе предлагал на основе BLToolkit сделать автоматический маппинг с транспортного слоя на прикладной.
Я же говорю — ты не понял НИ СЛОВА из того, что я писал тебе ранее.
Даже где-то обидно... ))
_>Но главное даже не это. Даже если б это было возможно, но — нахрена? Я бы понял, если б ты предложил ASN.1 или что еще как основной язык (но в случае с ASN.1 это полное безумие), но как промежуточный?
Потому что эффективная и надежная сериализация. Т.е. чтобы не тратить квантов внимания на эту область, в которой в случае ручной её реализации постоянно возникают ошибки и вообще оно происходит зачастую неэффекктивно.
А еще потому, что ASN.1 предлагает тебе trade-off изкаробки: можно выбирать из целой градации профилей кодирования, от самых эффективных по размеру пакета до самых эффективных по затрачиваемым ресурсам проца. И тебе несложно будет переключать эти профили. Например, если у какого-то клиента плохой пинг, то серверу стоит ужать трафик в сторону такого клиента в НЕСКОЛЬКО РАЗ. А если хороший, то стоит тратить на такого клиента меньше тиков процессора.
Никакая другая технология вот всеми этими совокупными св-вами НЕ обладает. Более того. На сегодня идёт развитие в нужном направлении только ASN.1.
Остальные конкурирующие технологии мертвы — будучи разработаны однажды для чего-то, быстро становятся невостребованы по окончании проекта, в котором были применены. Эдакая "одноразовость", мертвечинка...
_>Но я не понимаю, в чем именно ты видишь проблему генерации кода сериализации. В самой кодогенерации или в оптимальности сгенерированного кода?
И там и там.
А еще в ошибках, т.е. тупо в багах. Был я как-то на одном проекте, так только в коде бинарной кастомной сериализации отловил порядка десятка ошибок. Причем, ошибки удачно максировались тем, что периодически шла не только дельта, но и абсолютные значения, угу. Поэтому ошибки в дельтах приводили лишь к "кратковременному вранью", которое списывали на притормаживание. )) А не было никакого притормаживания, были баги.
V>>Потому что удобных инструментов для разработки своих языков полно.
_>Разве с этим кто-то спорит?
V>>ANTLR
_>Ну и что ANTLR-то? Nemerle.Peg не сложнее
Он не не сложнее, а беднее на многие-многие порядки. Он пуст как абстрактное zero. Как Мухосранк посреди Сибири. ))
Ты, таки, взял бы в руки ANTLR. Это мощнейшая визуальная система разработки и отладки грамматик.
В принципе, ПОСЛЕ отладки грамматики в ANTLR запросто можно закодировать её в чем угодно, хоть даже в Nemerle.
В ANTLR ты можешь вести быструю разработку языка, вводить новые конструкции в него и достоверно на каждом шаге знать — получается ли у тебя язык однозначным на любых входных цепочках или уже нет. В случае PEG ты об этом не узнаешь до тех пор, пока тебе на входе не встретится такая цепочка. И вот ты создашь в JIRA тикет, вынужден будешь открыть исходник своего парсера и начать медитировать.
_>а удобная интерполяция строк как в Nemerle это musthave для кодогенерации.
Да это вообще для кодогенерации пофиг. Экономия 1% усилий. Проблема чаще не в кодогенерации, а в модели, по которой она происходит. А модель зависит от языка. А вот разработать сам язык — это и есть самая мякотка.
_>Прочитал, но не понял, на что ты обиделся.
Я не принимаю простых "я не согласен", "тут не прав", "а это грязный хак" (чего???) и прочей такой фигни.
Технический спор это:
— вот тут ты не прав, потому что: ...
или
— а здесь я бы предложил альтернативу, которая в сравнении с исходным вариантом даёт следующее: ...
И т.д. в этом же духе.
Всё остальное — это просто обмен какашками, в какую бы вежливую форму они ни были завёрнуты.
_>Ты понятие IDL трактуешь очень узко, IDL это не только CORBA и COM.
Я тебе дал вполне конкретное представление о том, что есть IDL, не наговаривай на конкретно CORBA или COM.
Почитай про тот же ICE:
https://en.wikipedia.org/wiki/Internet_Communications_Engine
В этом месте тебе должно быть уже понятно отличие Google protobuf или Microsoft bond от фреймворков подобного рода.
Не надо путать фреймворки сугубо для бинарной сериализации и фреймворки для удалённых вызовов методов объектов.
Потому что в первом случае ты сам работаешь напрямую с транспортным слоем, а во втором тебе транспортный слой, считай, не видим ("прозрачен", согласен IT-терминологии).
Поэтому, коль я по косвенным признакам догадался о неверном использовании тобой абревиатуры IDL, я предложил тебе фреймворк другого типа — ASN.1.
Почему именно он — он лучший на сегодня из всех.
Даже если тебе не нравится сам ASN.1 — я уже сказал что надо делать — надо просто написать свой примитивнейший DSL, который на выходе даст ASN.1.
Хотя, даже сам ASN.1 весьма удобен, просто надо потратить хотя бы час-другой времени на его изучение. Например, в этом языке есть ЯВНАЯ поддержка optional-семантики.
А еще в языке есть параметрические типы. ))
Т.е. можно задать генерик-описание сообщения, например:
Point{DataType} ::= SEQUENCE {
x DataType,
y DataType
}Зависимости можно протягивать:
Move{DataType} ::= SEQUENCE {
from Point{DataType},
to Point{DataType}
}а потом специализировать
UpdateXXX ::= CHOICE {
i [0] Move<int32>,
f [1] Move<float>,
d [2] Move<double>
}А еще для этих параметрических типов можно описывать классы типов:
LevelParams ::= CLASS {
&level-field-width int32,
&level-field-height int32,
}
Move-PDU{LevelParams : param} ::= SEQUENCE {
x INTEGER (0..param.&level-field-width),
y INTEGER (0..param.&level-field-height)
}И вот для разных уровней могут быть разные кодировки сообщений в потоке, потому что битовая ширина x и y может быть разной.
Есть еще много других прикольных плюшек, чего стоит один только тип SET — это же бомба!
Кароч, я много одно время смотрел альтернативных технологий, но они по выразительности и мощи проигрывают ASN.1, как первоклашки проигрывают профессору ВУЗ-а в области математики. ))
_>Я на это тоже уже отвечал. ASN.1 compiler генерирует то, что генерирует, а не то, что мне нужно.
У некоторых компилятором маппинг можно настраивать.
_>При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет.
Опять же — есть:
http://bnotes.sourceforge.net/
Вот тебе с метаинформацией для C#:
[ASN1Sequence ( Name = "TestSequence", IsSet = false )]
public class TestSequence
{
private long field1_ ;
[ASN1Element ( Name = "field1", IsOptional = false , HasTag = false , HasDefaultValue = false ) ]
public long Field1 {
get { return field1_; }
set { field1_ = value; }
}
..._>То есть в Эрланге тупл вместо рекорда — нельзя, typespec — нельзя, в C# struct вместо class — нельзя, использовать алиас на существующий тип данных указав для него внешний сериализатор — нельзя, сгенерировать Equals/EqualityComparer/или что еще в голову взбредет — нельзя.
Здра моя ра!
А не путаете ли вы, батенька, транспортный слой с прикладным?
Или у тебя там всё вперемешку?
Блин, во всех этих сетевых делах ничего изобретать не надо — всё уже изобретено до нас. Например, любые обращения к серверу БД — это точно такое же обращение к сетевому внешнему сервису. И точно так же существует некий слой DAL, дальше которого сугубо транспортные типы данных не пролезают.
_>Если и ошибся в каких деталях, все равно рано или поздно уткнусь в ограничения.
Потому что ты уткнулся в архитектуру без DAL.
_>То есть используя ASN.1 как таргет-язык для генерации, я просто не могу решать те задачи, которые ставлю перед исходным DSL.
ASN.1 тут не при чем от слова совсем, хосподя...
Я тебе предлагал на основе BLToolkit сделать автоматический маппинг с транспортного слоя на прикладной.
Я же говорю — ты не понял НИ СЛОВА из того, что я писал тебе ранее.
Даже где-то обидно... ))
_>Но главное даже не это. Даже если б это было возможно, но — нахрена? Я бы понял, если б ты предложил ASN.1 или что еще как основной язык (но в случае с ASN.1 это полное безумие), но как промежуточный?
Потому что эффективная и надежная сериализация. Т.е. чтобы не тратить квантов внимания на эту область, в которой в случае ручной её реализации постоянно возникают ошибки и вообще оно происходит зачастую неэффекктивно.
А еще потому, что ASN.1 предлагает тебе trade-off изкаробки: можно выбирать из целой градации профилей кодирования, от самых эффективных по размеру пакета до самых эффективных по затрачиваемым ресурсам проца. И тебе несложно будет переключать эти профили. Например, если у какого-то клиента плохой пинг, то серверу стоит ужать трафик в сторону такого клиента в НЕСКОЛЬКО РАЗ. А если хороший, то стоит тратить на такого клиента меньше тиков процессора.
Никакая другая технология вот всеми этими совокупными св-вами НЕ обладает. Более того. На сегодня идёт развитие в нужном направлении только ASN.1.
Остальные конкурирующие технологии мертвы — будучи разработаны однажды для чего-то, быстро становятся невостребованы по окончании проекта, в котором были применены. Эдакая "одноразовость", мертвечинка...
_>Но я не понимаю, в чем именно ты видишь проблему генерации кода сериализации. В самой кодогенерации или в оптимальности сгенерированного кода?
И там и там.
А еще в ошибках, т.е. тупо в багах. Был я как-то на одном проекте, так только в коде бинарной кастомной сериализации отловил порядка десятка ошибок. Причем, ошибки удачно максировались тем, что периодически шла не только дельта, но и абсолютные значения, угу. Поэтому ошибки в дельтах приводили лишь к "кратковременному вранью", которое списывали на притормаживание. )) А не было никакого притормаживания, были баги.
V>>Потому что удобных инструментов для разработки своих языков полно.
_>Разве с этим кто-то спорит?
V>>ANTLR
_>Ну и что ANTLR-то? Nemerle.Peg не сложнее
Он не не сложнее, а беднее на многие-многие порядки. Он пуст как абстрактное zero. Как Мухосранк посреди Сибири. ))
Ты, таки, взял бы в руки ANTLR. Это мощнейшая визуальная система разработки и отладки грамматик.
В принципе, ПОСЛЕ отладки грамматики в ANTLR запросто можно закодировать её в чем угодно, хоть даже в Nemerle.
В ANTLR ты можешь вести быструю разработку языка, вводить новые конструкции в него и достоверно на каждом шаге знать — получается ли у тебя язык однозначным на любых входных цепочках или уже нет. В случае PEG ты об этом не узнаешь до тех пор, пока тебе на входе не встретится такая цепочка. И вот ты создашь в JIRA тикет, вынужден будешь открыть исходник своего парсера и начать медитировать.
_>а удобная интерполяция строк как в Nemerle это musthave для кодогенерации.
Да это вообще для кодогенерации пофиг. Экономия 1% усилий. Проблема чаще не в кодогенерации, а в модели, по которой она происходит. А модель зависит от языка. А вот разработать сам язык — это и есть самая мякотка.
_>Прочитал, но не понял, на что ты обиделся.
Я не принимаю простых "я не согласен", "тут не прав", "а это грязный хак" (чего???) и прочей такой фигни.
Технический спор это:
— вот тут ты не прав, потому что: ...
или
— а здесь я бы предложил альтернативу, которая в сравнении с исходным вариантом даёт следующее: ...
И т.д. в этом же духе.
Всё остальное — это просто обмен какашками, в какую бы вежливую форму они ни были завёрнуты.