Здравствуйте, eao197, Вы писали:
E>Ситуация несколько сложнее. Язык версии 1.* вроде как есть и поддерживается пока только одним компилятором DMD на платформах x86 Windows и Linux. Под него существуют некоторые библиотеки. И все. Совершенствованием 1.* больше никто не занимается. Новые библиотеки создаются уже для 2.*. Даже у Tango появилась ветка для D 2.0, хотя сама Tango так до 1.0 пока и не дошла.
Чего это вдруг одним компилятором ? Д 1.хх имеет фронтенд для Гнуси, и тем самым для всего-всего.
E>Т.е. если сейчас заложиться на диалект 1.* для долгосрочных проектов, то это означает, что в скором времени эти проекты окажутся привязанными к умершей ветке языка с ограниченным количеством инструментов и библиотек. Поскольку я не слышал о том, что кто-то хочет дальше заниматься D 1.0.
На самом деле перенос либ между 1.хх и 2.хх несложен. Я переносил DFL на 2.хх без напряга.
E>Я читаю только news.digitalmars.announce, про паттерн-матчинг не слышал.
Вроде бы это обсуждалось в Digitalmars.D
E>Тупли там на основе шаблонов. Имхо, более простые в освоении и использовании, чем в C++0x.
Их нельзя возвращать из функций, к сожалению.
E>У вас же есть Erlang, зачем вам что-то еще?
Ну, как минимум, иногда хочется standalone приложения. Да и быстродействие совсем другое у Д.
На самом деле, легковесных потоков очень не хватает. Возможно, привык я к ним
E>К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз.
Как это ? Наверное, у меня мозга не в том направлении думает.. Поясните, плиззз
Здравствуйте, gandalfgrey, Вы писали:
G>Чего это вдруг одним компилятором ? Д 1.хх имеет фронтенд для Гнуси, и тем самым для всего-всего.
По имеющимся у меня сведениям, GDC приказал долго жить. А его разработчик подключился к разработке комплятора D на основе LLVM.
G>На самом деле перенос либ между 1.хх и 2.хх несложен.
Ну ей богу, зло берет по 10 раз все это объяснять. В 2.* появилась транзитивная константность. Все. Любой старый D-шный код, который хочет получить существенные преимущества от D 2.* (за счет иммутабельности, например), должен быть не просто переписан, а перепроектирован.
G>Я переносил DFL на 2.хх без напряга.
А DFL, насколько я помню, всего лишь биндинг к FLTK.
E>>К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз. G>Как это ? Наверное, у меня мозга не в том направлении думает.. Поясните, плиззз
ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandalfgrey, Вы писали: E>По имеющимся у меня сведениям, GDC приказал долго жить. А его разработчик подключился к разработке комплятора D на основе LLVM.
LLVM только для 2.хх будет ?
E>Ну ей богу, зло берет по 10 раз все это объяснять. В 2.* появилась транзитивная константность. Все. Любой старый D-шный код, который хочет получить существенные преимущества от D 2.* (за счет иммутабельности, например), должен быть не просто переписан, а перепроектирован.
Ключевое слово — "который хочет". Если надо просто перенести ( чтоб собиралось и работало ) — то это несложно
E>А DFL, насколько я помню, всего лишь биндинг к FLTK.
DFL, the D Forms Library, is an easy to use user interface toolkit for the D programming language. It brings you a high level, easy to use interface, abstracted from the native API.
Он и вправду нативный, без подлежащих либ или врапперов
E>ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.
Нууууууууу...это все не то. АСН.1 требует предварительного описания, к примеру
Здравствуйте, gandalfgrey, Вы писали:
E>>По имеющимся у меня сведениям, GDC приказал долго жить. А его разработчик подключился к разработке комплятора D на основе LLVM. G>LLVM только для 2.хх будет ?
Пока он делается только для 1.*, поддержка 2.0 в нем пока экспериментальная. Что и не удивительно, т.к. какой-либо законченой спецификации D 2.0 пока нет.
E>>Ну ей богу, зло берет по 10 раз все это объяснять. В 2.* появилась транзитивная константность. Все. Любой старый D-шный код, который хочет получить существенные преимущества от D 2.* (за счет иммутабельности, например), должен быть не просто переписан, а перепроектирован. G>Ключевое слово — "который хочет". Если надо просто перенести ( чтоб собиралось и работало ) — то это несложно
Как раз в моем случае "который хочет".
E>>А DFL, насколько я помню, всего лишь биндинг к FLTK. G>DFL, the D Forms Library, is an easy to use user interface toolkit for the D programming language. It brings you a high level, easy to use interface, abstracted from the native API. G>Он и вправду нативный, без подлежащих либ или врапперов
Да, это я с FLTKd перепутал.
E>>ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка. G>Нууууууууу...это все не то. АСН.1 требует предварительного описания, к примеру
Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Пока он делается только для 1.*, поддержка 2.0 в нем пока экспериментальная. Что и не удивительно, т.к. какой-либо законченой спецификации D 2.0 пока нет.
Есть еще OpenD. Или он тоже окуклился ?
E>Как раз в моем случае "который хочет".
Ну, тогда — да, надо думать головным мозгом над архитектурой.
E>Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний
Автоматически хотелось бы ! Весь вопрос в том, как быть, ежели наборы типов в момент сериализации и десериализации — разные.
Здравствуйте, gandalfgrey, Вы писали:
E>>Пока он делается только для 1.*, поддержка 2.0 в нем пока экспериментальная. Что и не удивительно, т.к. какой-либо законченой спецификации D 2.0 пока нет. G>Есть еще OpenD. Или он тоже окуклился ?
Ну так в том-то и дело. Причем, если бы константность не была транзитивной, то проблем с переносом кода из D 1.* в D 2.* лично у меня было бы гораздо меньше.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну так в том-то и дело. Причем, если бы константность не была транзитивной, то проблем с переносом кода из D 1.* в D 2.* лично у меня было бы гораздо меньше.
При БОЛЬШОМ желании это можно обьехать, но код становится некузявым. Да и рукописной работы непропорционально много
Здравствуйте, gandalfgrey, Вы писали:
E>>Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний G>Автоматически хотелось бы ! Весь вопрос в том, как быть, ежели наборы типов в момент сериализации и десериализации — разные.
А как быть, если с одной стороны 2x2=?, а с другой — ?=78, ы? Вот так же и здесь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
E>>>Нууууууу... Я вообще не представляю, как можно делать нормальную сериализацию без внешних описаний G>>Автоматически хотелось бы ! Весь вопрос в том, как быть, ежели наборы типов в момент сериализации и десериализации — разные.
ГВ>А как быть, если с одной стороны 2x2=?, а с другой — ?=78, ы? Вот так же и здесь.
У динамически-типизированных языков здесь есть преимущество перед статически-типизированными. Если в сериализованном представлении есть метки типов, то возможно восстановление данных без особых проблем. Например, пусть в сериализованном представлении у нас есть что-то вроде:
01 -- тип данных Array
03 -- его длина в элементах.
-- Начинаются элементы массива.
02 -- тип данных Symbol или Atom (в зависимости от языка).
05 -- его длина.
48 45 4C 4C 4F -- Hello -- его значение.
03 -- тип данных Integer.
01 -- его длина.
10 -- его значение.
04 -- тип данных String.
03 -- его длина.
42 79 65 -- Bye -- его значение.
то десериализатор в динамически-типизированном языке (вроде Ruby, Python или Erlang) сможет вернуть полностью восстановленный объект. Что-то вроде:
Если программу интересует только третий элемент из массива, то этот элемент может быть легко извлечен и обработан. Как я понимаю, gandalfgrey привык к подобным штукам в Erlang-е, где помимо динамической типизации есть еще и паттерн-матчинг, который позволяет легко разбираться со структурой полученных данных. Т.е. делать что-то вроде:
process_data({_,_,S}) -> ...какая-то обработка...
process_data(_) -> ...обработка неподходящих по формату данных...
receive_and_process_data(source) ->
S = receive_data(source),
D = deserialize_data(S),
process_data(D).
В статически-типизированном языке такие фокусы просто-так не получатся. Нужно будет манипулировать какими-то векторами Variant-ов или чем-то в этом духе. Но и это становится практически невозможным, если сериализация поддерживает ООП, т.е. когда можно сериализовать объект и десериализовать его на другой стороне. Причем здесь нужно поддерживать несколько специфических ситуаций:
— на принимающей стороне состав полей объекта может отличаться от состава полей на сериализующей стороне;
— на принимающей стороне может быть неизвестен тип объекта, который был сериализован.
Обработка этих ситуаций требует дополнительных описаний для подсистемы сериализации/десериализации. Именно поэтому средства сериализации с более-менее серьезными возможностями (ASN.1, Google ProtoBuf, ObjESSty) требуют внешнего описания структуры сериализуемых данных.
И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет:
1) отсутствия в сериализованном потоке полей-маркеров типа поля и его длины. Так, показаный выше пример без маркеров может выглядеть так:
03 -- Длина массива в элементах.
-- Начинаются элементы массива.
05 -- Длина первого элемента.
48 45 4C 4C 4F -- Hello -- его значение.
10 -- Второй элемент.
03 -- Длина третьего элемента.
42 79 65 -- Bye -- его значение.
т.е. 12 байт вместо 17.
2) некоторые значения полей могут опускаться и не сохраняться в сериализованном представлении, если они имеют одно из стандартных значений. Например, если поле Handshaking::CompressionAlgorithm в большинстве случаев имеет значение "ZLib", то его можно вообще не сериализовать.
3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита.
Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр.
PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey
Что-то я не совсем понял, о чём ты сейчас. Я как раз и предполагаю, что структуры данных должны быть предварительно описаны на обоих сторонах канала. Если полученный пакет не удовлетворяет ожидаемому формату (длина отличается, CRC не совпадает, какого-нибудь маркера в нужном месте не оказалось, ещё что-то), то считаем его просто ошибкой передачи — и всё. Какие ещё неожиданно взявшиеся структуры объектов? Зачем?
Да собственно говоря, никаких самоописаний не бывает в природе. Если уж данные содержат некие метаданные, содержащие "описание структуры", то это как минимум означает, что приёмник имеет в своём распоряжении некую программу, которая строит по известным ей маркерам "объект" или "структуру", или "именованный список", называйте, как хотите. Дальше вопрос только в необходимой детализации этой маркировки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Если ты хотел узнать об одном из источников "тормозов" динамических языков, то это был он.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
E>>PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey
ГВ>Что-то я не совсем понял, о чём ты сейчас. Я как раз и предполагаю, что структуры данных должны быть предварительно описаны на обоих сторонах канала. Если полученный пакет не удовлетворяет ожидаемому формату (длина отличается, CRC не совпадает, какого-нибудь маркера в нужном месте не оказалось, ещё что-то), то считаем его просто ошибкой передачи — и всё. Какие ещё неожиданно взявшиеся структуры объектов? Зачем?
В том-то и дело, что в динамических языках это знание может быть существенно другим, чем в статически-типизированном языке. Если убрать из рассмотрения CRC, то динамический язык менее требователен к структурам данных. Ну, допустим, пишем мы сервер какой-нибудь on-line игры (пример с потолка, никогда это не писал ). И решаем, что будем отдавать на запрос статуса игрока набор их [имя, количество очков, уровень жизни, уровень мастерства, расположение на карте]. Клиент знает только этот набор, но может не знать даже какими типами данных представлены элементы в этом наборе. Имя -- это строка, атом или структура? Уровень жизни -- это Fixnum или Float? Расположение на карте -- это (X, Y, Z) или (X, Y, Time), или (X, Y, Z, Time)?
А по большому счету для динамически-типизированного языка это без разницы. Поскольку он позволяет легко все это переваривать:
player_data = deserialize(data)
name = player_data[ 0 ]
position = player_data[ 4 ]
puts "player #{name} is on #{position}"
Все будет работать
ГВ>Да собственно говоря, никаких самоописаний не бывает в природе.
ASN.1 BER (он же TLV -- Tag-Length-Value) или s-expressions, или XML -- практически самоописания данных.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>то десериализатор в динамически-типизированном языке (вроде Ruby, Python или Erlang) сможет вернуть полностью восстановленный объект.
В том-то и дело !
T={crysis,[{salary,low},{employers,10},{panic,yes}],2008}.
B=term_to_binary(T).
B.
<<131,104,3,100,0,6,99,114,121,115,105,115,108,0,0,0,3,104,2,100,0,6,115,97,
108,97,114,121,100,...>>
binary_to_term(B).
{crysis,[{salary,low},{employers,10},{panic,yes}],2008}
Хотелось бы такого же и в статически-типизированных языках. ( Я понимаю, что это малореально... )
E>И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет:
Разница есть, но она не очень значительна ( кроме особых случаев ). Обычно приемлемы даже текстовые форматы передачи данных, типа JSON.
E>3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита.
GZIP тоже позволяет обжать поток, если порции не слишком маленькие
E>Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр.
Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ? А потом что, после того, как я сгенерирую десериализатор на принимающей стороне ? Он вернет мне значение одного и только одного типа, которое будет представлять собой некий сложный контейнер с данными. Тем самым типизация как бы замыливается.
E>PS. Гена, писал вроде ответ тебе, а получился ответ для gandalfgrey
Как бы да !
Вот подумал — может, это вообще некорректная формулировка проблемы ? Уж не противоестественное ли это желание — требовать от некоего языка, чтоб он по щелчку пальцев менял свою жесткость, форму и цвет ? 8)))))
Здравствуйте, gandalfgrey, Вы писали:
G>Хотелось бы такого же и в статически-типизированных языках. ( Я понимаю, что это малореально... )
Малореально.
E>>И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет: G>Разница есть, но она не очень значительна ( кроме особых случаев ). Обычно приемлемы даже текстовые форматы передачи данных, типа JSON.
Ну это сильно от задачи зависит. Когда речь зайдет о сериализации/десериализации сотен тысяч значений в секунду, в дело вступят и маленький размер, и двоичное представление.
E>>3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита. G>GZIP тоже позволяет обжать поток, если порции не слишком маленькие
Опять же от задачи зависит. У меня в некоторых случаях использование GZip снижало пропускную способность вдвое, при серьезной нагрузке на CPU.
E>>Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр. G>Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ? А потом что, после того, как я сгенерирую десериализатор на принимающей стороне ? Он вернет мне значение одного и только одного типа, которое будет представлять собой некий сложный контейнер с данными. Тем самым типизация как бы замыливается.
Так здесь другой вопрос возникает: ну передаст узел A узлу B новые данные, структуру которых B не знает. И что B будет с ними делать? Не зная структуру и смысл значений из все равно не обработать. Поэтому, если обновляется структура информации, то это сопровождается и обновлением софта на узлах A и B.
Есть, однако, маленький частный случай, когда B является всего лишь промежуточным звеном между A и C. В этом случае B должен уметь брать новые данные от A и отдавать их C без потери чего-либо. Для таких случаев могут быть частные решения. Я у себя сделал такое понятие, как subclassing by extension: т.е. узлы A, B и C должны знать про некий базовый тип Base. Далее узлы A и C могут делать от него любое количество наследников, о которых B даже не будет знать. Эти наследники специальным образом помечаются. Благодоря этому, при их сериализации значения специальным образом упаковываются. Узел B при десериализации понимает, что он получил объек-наследник Base, хотя и не знает его структуры. То, что B не знает, специальным образом сохраняется при десериализации и восстанавливается при новой сериализации. Поэтому B может легко ретранслировать данные между A и C, о которых он не знает.
G>Вот подумал — может, это вообще некорректная формулировка проблемы ? Уж не противоестественное ли это желание — требовать от некоего языка, чтоб он по щелчку пальцев менял свою жесткость, форму и цвет ? 8)))))
Некорректная. У каждого семейства языков есть свой набор правил и идиом, с которыми нужно смирится и воспринимать их как данность. В общем -- в каждом монастыре, свой устав и со своим туда лучше не лезть
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
ГВ>>Что-то я не совсем понял, о чём ты сейчас. Я как раз и предполагаю, что структуры данных должны быть предварительно описаны на обоих сторонах канала. Если полученный пакет не удовлетворяет ожидаемому формату (длина отличается, CRC не совпадает, какого-нибудь маркера в нужном месте не оказалось, ещё что-то), то считаем его просто ошибкой передачи — и всё. Какие ещё неожиданно взявшиеся структуры объектов? Зачем?
E>В том-то и дело, что в динамических языках это знание может быть существенно другим, чем в статически-типизированном языке. Если убрать из рассмотрения CRC, то динамический язык менее требователен к структурам данных.
Для статически типизированного языка эта требовательность просто переносится на уровень протокола. Можно ослабить требования, можно усилить.
E>Ну, допустим, пишем мы сервер какой-нибудь on-line игры (пример с потолка, никогда это не писал ). И решаем, что будем отдавать на запрос статуса игрока набор их [имя, количество очков, уровень жизни, уровень мастерства, расположение на карте]. Клиент знает только этот набор, но может не знать даже какими типами данных представлены элементы в этом наборе. [...]
На таком уровне несложно абстрагироваться и в статически типизируемом языке. Передавай строку — да и всё. Натрави зиппер, он её ещё и ужмёт. В сущности, это простейшая ситуация. Гораздо интересней, например, если нужно сообразить — имя это "Name", "ActorName", или "ActorPublicAlias"?
То есть, понимаешь, в чём парадокс. Если структура данных определена, то тип, используемый для кодирования одного элемента не особо важен с любой точки зрения. А если структура предполагается быть неопределённой, то всплывает такая куча вопросв, что сразу становится понятным, что её лучше определить и как следствие — вернуться к малозначимости вопроса о типе, кодирующем "элементарную ячейку". То есть так или иначе, но приходится возвращаться к тому или иному виду предварительного согласования структур данных, используемых дляобмена информацией.
ГВ>>Да собственно говоря, никаких самоописаний не бывает в природе.
E>ASN.1 BER (он же TLV -- Tag-Length-Value) или s-expressions, или XML -- практически самоописания данных.
А если приёмник не умеет парсить ASN или XML?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandalfgrey, Вы писали:
E>>И еще один важный аспект. Наличие внешних описаний структуры сериализуемых данных позволяет достигать высокой компактности сериализованного представления за счет: G>Разница есть, но она не очень значительна ( кроме особых случаев ). Обычно приемлемы даже текстовые форматы передачи данных, типа JSON.
Это бабушка надвое сказала.
E>>3) ASN.1 в PER-кодировке идет еще дальше -- он позволяет производить битовую упаковку. Т.е. если какое-то поле принимает значения в диапазоне 0..6, то для представления этого поля будут заняты всего-лишь три бита. G>GZIP тоже позволяет обжать поток, если порции не слишком маленькие
+1
E>>Ну и по внешним описаниям могут быть сгенерированные специализированные сериализаторы/десериализаторы, которые будут работать намного быстрее поэлементного разбора входного потока с анализом типа и размера очередного элемента, создания под него соответствующего объекта и пр. G>Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ? А потом что, после того, как я сгенерирую десериализатор на принимающей стороне ? Он вернет мне значение одного и только одного типа, которое будет представлять собой некий сложный контейнер с данными. Тем самым типизация как бы замыливается.
Не-а. Вслед за генерацией нового десериализатора нужно ответить на вопрос: а зачем он здесь нужен? Сгенерил ты десериализатор, что ты с ним дальше намерен делать? Ладно, десериализовал данные. Куда их теперь девать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandalfgrey, Вы писали:
G>Дык ить ! Они будут опять-таки статическими, эти сериализаторы. А как быть, ежели мне надо во время работы софта передать новый тип данных ? Сначала передать описание ?
Была такая древняя книжка
Название которой не соответсвовало содержанию. В ней говорилось о том как передать новый класс на клиентскую сторону в форме потока байт-кодов, загрузить и
выполнить с целью организации распределенных вычислений
Здравствуйте, eao197, Вы писали:
E>Ну это сильно от задачи зависит. Когда речь зайдет о сериализации/десериализации сотен тысяч значений в секунду, в дело вступят и маленький размер, и двоичное представление.
Потому я и написал, что в большинстве случаев ( но не для всех ). Мы выбираем между роскошью удобного для нас представления данных и компактностью упакованных форматов.
E>Опять же от задачи зависит. У меня в некоторых случаях использование GZip снижало пропускную способность вдвое, при серьезной нагрузке на CPU.
Скорее всего, словарь ГЗИПа был слишком большой. Опция -1 уменьшает его размер и весьма ускоряет пожатие.
E>Так здесь другой вопрос возникает: ну передаст узел A узлу B новые данные, структуру которых B не знает. И что B будет с ними делать? Не зная структуру и смысл значений из все равно не обработать. Поэтому, если обновляется структура информации, то это сопровождается и обновлением софта на узлах A и B.
Тут я вижу 2 пути :
— можно использовать некие встроенные знания на узле В о том, как интерпретировать пришедшие данные в пределах понимания узлом В их структуры. Это не всегда применимо и несколько ограничено
— можно опционально передавать и алгоритмы для обработки пришедших данных
calc_mid(L)->calc_mid(L,fun(X)->abs(X) end).
calc_mid([],_)->0;
calc_mid(L,F)->
lists:foldl(fun(X,A)->A+F(X) end,0,L)/ length(L).
------------------------------------------
calc_mid([1,3,4.2,6]).
работает
calc_mid([{3.1,5},{-2,0},{5.5,2}],fun({X,Y})->math:sqrt(X*X+Y*Y) end).
тоже работает
В данном случае у нас будет приходить список значений, а для второго случая еще и алгоритм, по которому считать.
Может показаться, что это близко к горячей замене кода, но это совсем не так.
E>Есть, однако, маленький частный случай, когда B является всего лишь промежуточным звеном между A и C. В этом случае B должен уметь брать новые данные от A и отдавать их C без потери чего-либо. Для таких случаев могут быть частные решения. Я у себя сделал такое понятие, как subclassing by extension: т.е. узлы A, B и C должны знать про некий базовый тип Base. Далее узлы A и C могут делать от него любое количество наследников, о которых B даже не будет знать. Эти наследники специальным образом помечаются. Благодоря этому, при их сериализации значения специальным образом упаковываются. Узел B при десериализации понимает, что он получил объек-наследник Base, хотя и не знает его структуры. То, что B не знает, специальным образом сохраняется при десериализации и восстанавливается при новой сериализации. Поэтому B может легко ретранслировать данные между A и C, о которых он не знает.
Это ОЧЕНЬ ограниченный случай, как мне кажется
E>Некорректная. У каждого семейства языков есть свой набор правил и идиом, с которыми нужно смирится и воспринимать их как данность. В общем -- в каждом монастыре, свой устав и со своим туда лучше не лезть
Дык хочется же ! Причем и того, и того одновременно ( таблеток от жадности тоже... ) 8)))))
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>Была такая древняя книжка G_K>Название которой не соответсвовало содержанию. В ней говорилось о том как передать G_K>новый класс на клиентскую сторону в форме потока байт-кодов, загрузить и G_K>выполнить с целью организации распределенных вычислений
Я так понимаю, что там исключительно о Жабовской специфике ? Или там есть некие языконезависимые идеи ?
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Gluk_Kazan, Вы писали:
G_K>>Была такая древняя книжка G_K>>Название которой не соответсвовало содержанию. В ней говорилось о том как передать G_K>>новый класс на клиентскую сторону в форме потока байт-кодов, загрузить и G_K>>выполнить с целью организации распределенных вычислений
G>Я так понимаю, что там исключительно о Жабовской специфике ? Или там есть некие языконезависимые идеи ?
Исключительно языкозависимые. Но книжка по тому времени — пионерская
Если уж данные содержат некие метаданные, содержащие "описание структуры", то это как минимум означает, что приёмник имеет в своём распоряжении некую программу, которая строит по известным ей маркерам "объект" или "структуру", или "именованный список", называйте, как хотите. 
