Re[9]: Опциональные типы
От: meadow_meal  
Дата: 25.02.17 03:12
Оценка: +2
Здравствуйте, vdimas, Вы писали:

_>>По поводу вложенного Optional мне добавить нечего.

V>Тебе ответить нечего, вестимо, потому что в 3-х соснах заплутал.
V>...
V>Прямо отсюда должно стать понятным, что если под это СПЕЦИАЛЬНОЕ значение можно выделить некое значение из исходного диапазона, то надобность складывать типы резко отпадает. Трюк стар как мир, а поди ж ты.

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

V>Потому что IDL не предназначена для эффективной сериализации by design, вестимо.


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

Соответственно все остальное об IDL пропускаю.

V>Я предложил ASN.1 ровно по одной причине — это пример сугубо текстового описания на выходе, под которое можно выбирать профили кодирования. Именно этим мне ASN.1 и симпатичен.


Я на это тоже уже отвечал. ASN.1 compiler генерирует то, что генерирует, а не то, что мне нужно. При этом кодогенерация вообще никак не контролируется, системы метаданных как например в protobuf у него нет. То есть в Эрланге тупл вместо рекорда — нельзя, typespec — нельзя, в C# struct вместо class — нельзя, использовать алиас на существующий тип данных указав для него внешний сериализатор — нельзя, сгенерировать Equals/EqualityComparer/или что еще в голову взбредет — нельзя. Если и ошибся в каких деталях, все равно рано или поздно уткнусь в ограничения. То есть используя ASN.1 как таргет-язык для генерации, я просто не могу решать те задачи, которые ставлю перед исходным DSL.

Но главное даже не это. Даже если б это было возможно, но — нахрена? Я бы понял, если б ты предложил ASN.1 или что еще как основной язык (но в случае с ASN.1 это полное безумие), но как промежуточный?

Я так понимаю вот это твой ответ:
> А вот для back-end-a для сетки надо брать что-то надёжное готовое.
> Потому что иначе надо будет потратить заметное кол-во человекочасов для рождения альтернативы, как минимум не уступающей в кач-ве и надежности уже имеющимся разработкам.

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

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


Разве с этим кто-то спорит?

V>ANTLR


Ну и что ANTLR-то? Nemerle.Peg не сложнее, а удобная интерполяция строк как в Nemerle это musthave для кодогенерации. Ты с чем конкретно споришь-то?

V>http://www.rsdn.org/forum/philosophy/6706569.1

V>Почитай, что и в каком виде ты там наотвечал.

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