Ada_Ru форум

Обсуждение языка Ада

Ada и XML

Оставить новое сообщение

Сообщения

Vadim Godunko
Ada и XML
2006-02-17 16:24:17

Добрый вечер!

 

Некоторое время назад ACM организовала специальную группу по

стандартизации API для обработки XML в программах на Ada. Поскольку похоже, что в этой рассылке многие используют XML, то может имеет смысл проработать собственный вариант API и предложить его этой группе как вариант?

On Fri, Feb 17, 2006 at 07:24:17PM +0300, Vadim Godunko wrote:

Добрый вечер!

 

Некоторое время назад ACM организовала специальную группу по

стандартизации API для обработки XML в программах на Ada. Поскольку похоже, что в этой рассылке многие используют XML, то может имеет смысл проработать собственный вариант API и предложить его этой группе как вариант?

 

 

 

Я какое-то время занимался этим и немного "шарю", хотя разобраться во всех деталях спецификации так и не собрался. Давно когда-то делал парсер. Полгода назад решил сделать вторую попытку. Вот результат http://www.ada-ru.org/files/xml_io-0.1.zip

 

Как всегда недоделанный :-/

 

Идею обговаривал с Димой Анисимковым. Суть вкратце:

 

Два самых популярных интерфейса SAX и DOM. Первый быстр, но использует callback, что не всегда удобно. Второй более прямой, но обычно, имеет весь XML документ в памяти, что непригодно для потоковой обработки.

Более прямой вариант использовать pool методы вместо callback-ов. В Java это выродилось в STAX интерфейс, см. например

http://www.xml.com/pub/a/2003/09/17/stax.html

 

или google по "STAX XML"

 

Это и пытался сделать.

 

Как это будет на языке Ада см в архиве, test_xml_io.adb

 

Прототип едва работает, хотя не полностью реализует стандарт XML и еще почти не тестировался (DTD нет совсем).

Попытался сделать generic пакетом, чтоб потом получить автоматом

парсеры для String, Wide_String и Wide_Wide_String

В тоже API хочу добавить потдержку записи XML.

Думаю скорость разбора будет хорошая, специально избегал

лишнего копирования и динамической работы с памятью.

 

Можно оттолкнуться от этого.

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Можно оттолкнуться от этого.

 

Можно. Другой вариант тоже недоделанного парсера можно найти в дизайнере (source/designer/xml_tools*).

 

У меня на данный момент сформировались следующие мысли:

 

1. На мой взгляд было-бы очень удобно реализовать API по принципу ASIS-а, т.е. без тэговых типов и разновсяческого наследования. Для прикладной области, имеющей статическую структуру это даже хорошо.

2. Хранение строковых данных лучше всего осуществлять без преобразования в какую-либо кодировку. Любое преобразование кодировок a) требует затрат (иногда некислых), б) небиективно (т.е. выполнение To_X (A) /= To_Y (To_X (A)) для любого A из Y необязательно). К тому же существует целый ряд задач, когда собственно содержимое строки не требуется, а просто производится обработка структуры документа.

 

3. API должен предоставлять возможность сколь угодно "навороченной" реализации: от простейшей основанной на таблицах (мой вариант) до наикрутейшей предназначенной для работы в многопоточных серверных программах не останавливаемых десятилетиями.

 

4. Идея STAX мне понравилась, значительно удобнее SAX, но забывать про DOM и надстройки над ним тоже не стоит.

 

5. Использование generic-ов может быть разумно, но должно быть обоснованно.

Пожалуй это пока и всё... :(

1. На мой взгляд было-бы очень удобно реализовать API по принципу

ASIS-а, т.е. без тэговых типов и разновсяческого наследования. Для

прикладной области, имеющей статическую структуру это даже хорошо.

 

Я совсем мало понимаю в XML-наворотах, так что всего один маленький

комментарий. Раньше мне очень нравилось то, что ASIS определен

"без тэговых типов и разновсяческого наследования".

 

А вот теперь нравится существенно меньше...

Sergey I. Rybin wrote:

>1. На мой взгляд было-бы очень удобно реализовать API по принципу >ASIS-а, т.е. без тэговых типов и разновсяческого наследования. Для >прикладной области, имеющей статическую структуру это даже хорошо.

 

 

Я совсем мало понимаю в XML-наворотах, так что всего один маленький комментарий. Раньше мне очень нравилось то, что ASIS определен

"без тэговых типов и разновсяческого наследования".

 

А вот теперь нравится существенно меньше...

 

А чем не нравится? Можно подробнее?

А чем не нравится? Можно подробнее?

 

В случае ASIS получилось громоздкое, во многих местах

не сильно логичное, "трудноуправляемое" и абсолютно

неразвиваемое определение.

 

Мы с Васей затеяли чужими руками переписать определение ASIS

в ОО стиле (в виде диплома). С интерфейсами Ады 2005 должно

бы получиться совсем симпатично, но увы - студенты нынче не те.

И студентки - тоже :(

 

НО сама идея (пере)определить ASIS в ОО стиле мне нравится все

больше (поначалу я ее вообще не воспринял...)

 

Вообще-то это долгий разговор, и, жедательно, с развернутыми примерами

кода.

 

Я бы пробовал и так, и эдак. И смотрел, как лучше получается

Sergey I. Rybin wrote:

 

В случае ASIS получилось громоздкое, во многих местах

не сильно логичное, "трудноуправляемое" и абсолютно

неразвиваемое определение.

 

Мы с Васей затеяли чужими руками переписать определение ASIS

в ОО стиле (в виде диплома). С интерфейсами Ады 2005 должно

бы получиться совсем симпатично, но увы - студенты нынче не те.

И студентки - тоже :(

 

А можно поглядеть на результаты?

 

Я бы пробовал и так, и эдак. И смотрел, как лучше получается

 

Согласен.

On Fri, Feb 17, 2006 at 09:13:48PM +0300, Vadim Godunko wrote:

 

У меня на данный момент сформировались следующие мысли:

 

1. На мой взгляд было-бы очень удобно реализовать API по принципу ASIS-а, т.е. без тэговых типов и разновсяческого наследования. Для прикладной области, имеющей статическую структуру это даже хорошо.

 

Для парсера/райтера в принципе можно иметь не теговый лимитированный тип. Мне кажется что теговый тип подходит как источник для данных (у меня Text_Stream). Ведь заранее не известно откуда будет чиататься XML, из файла, сокета, памяти. Дима предлагал еще иметь возможность запихивать в парсер данные из того же потока.

 

2. Хранение строковых данных лучше всего осуществлять без преобразования в какую-либо кодировку. Любое преобразование кодировок a) требует затрат (иногда некислых), б) небиективно (т.е. выполнение To_X (A) /= To_Y (To_X (A)) для любого A из Y необязательно). К тому же существует целый ряд задач, когда собственно содержимое строки не требуется, а просто производится обработка структуры документа.

 

 

Я бы предложил иметь два интерфейса, String без перекодировки и

Wide_String с уже перекодированными данными. У меня получилось

сделать это в одном generic модуле и не кодировать два раза.

 

3. API должен предоставлять возможность сколь угодно "навороченной" реализации: от простейшей основанной на таблицах (мой вариант) до наикрутейшей предназначенной для работы в многопоточных серверных программах не останавливаемых десятилетиями.

 

 

Согласен, хотя если парсер будет соответствовать XML, то особо

простым его не сделаешь IMHO.

 

4. Идея STAX мне понравилась, значительно удобнее SAX, но забывать про DOM и надстройки над ним тоже не стоит.

 

 

Думаю надо начать со STAX, а DOM потом. Особо не вникал в DOM в XMLADA но на первый взгляд - нормально.

 

5. Использование generic-ов может быть разумно, но должно быть обоснованно.

 

Ну это скорее способ реализации, чтоб не кодировать два раза один алгоритм. Если мы оставим простор для разных реализаций, то такой подход будет просто частным случаем.

 

Пожалуй это пока и всё... :(

 

 

Наверное, в моих generic-ах тяжело сходу рабобраться, советую

посмотреть на XML_IO.Base_Readers. Там видно какой интерфейс

предоставляет парсер.

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Для парсера/райтера в принципе можно иметь не теговый лимитированный тип. Мне кажется что теговый тип подходит как источник для данных (у меня Text_Stream). Ведь заранее не известно откуда будет чиататься XML, из файла, сокета, памяти. Дима предлагал еще иметь возможность запихивать в парсер данные из того же потока.

 

Чтение из потока (на мой взгляд) - лучший вариант. Именно своей

универсальностью (можно подключить и файл, и соке

 

 

Я бы предложил иметь два интерфейса, String без перекодировки и

Wide_String с уже перекодированными данными. У меня получилось

сделать это в одном generic модуле и не кодировать два раза.

 

String без перекодировки? Такого не бывает. Пока живы non-ASCII char sets (например, EBCDIC) сама Standard.String - результат перекодировки. :(

А выбор String/Wide_String/Wide_Wide_String/Wide_Wide_Wide_String и т.д. должен осуществляться пользователем библиотеки. В качестве существующих реализаций можно предложить старый добрый String для char set кодировок и Unicode для всего остального (multibyte, wide). Но со String та же беда останется - она - результат потенциальной перекодировки.

 

>3. API должен предоставлять возможность сколь угодно "навороченной" >реализации: от простейшей основанной на таблицах (мой вариант) до >наикрутейшей предназначенной для работы в многопоточных серверных >программах не останавливаемых десятилетиями.

 

Согласен, хотя если парсер будет соответствовать XML, то особо

простым его не сделаешь IMHO.

 

Неважно, как он устроен внутри, важно - насколько его легко использовать и насколько при этом он расширяем для сложного использования.

 

 

Наверное, в моих generic-ах тяжело сходу рабобраться, советую

посмотреть на XML_IO.Base_Readers. Там видно какой интерфейс

предоставляет парсер.

 

Да нет, я думаю, что понял основную идею.

Мы с Васей затеяли чужими руками переписать определение ASIS

в ОО стиле (в виде диплома). С интерфейсами Ады 2005 должно

бы получиться совсем симпатично, но увы - студенты нынче не те.

И студентки - тоже :(

 

 

А можно поглядеть на результаты?

 

Мне вот уже по всем статьям и срокам НУЖНО поглядеть на результаты, но -

увы и ах! :(((

 

А самому делать (в результате этих мучений я вполне понимаю, как

это надо делать) времени нет...

Vadim Godunko wrote:

 

>Я бы предложил иметь два интерфейса, String без перекодировки и

>Wide_String с уже перекодированными данными. У меня получилось

>сделать это в одном generic модуле и не кодировать два раза.

 

String без перекодировки? Такого не бывает. Пока живы non-ASCII char sets (например, EBCDIC) сама Standard.String - результат перекодировки. :(

А выбор String/Wide_String/Wide_Wide_String/Wide_Wide_Wide_String и т.д. должен осуществляться пользователем библиотеки. В качестве существующих реализаций можно предложить старый добрый String для char set кодировок и Unicode для всего остального (multibyte, wide). Но со String та же беда останется - она - результат потенциальной перекодировки.

 

Тут мне подкатил облом - DOMString всегда представляется в UTF-16 с перекодировкой и нормализацией. Мда... Скоростью здесь может и не пахнуть...

On Sat, Feb 18, 2006 at 01:43:05PM +0300, Vadim Godunko wrote:

Maxim Reznik wrote:

 

Для парсера/райтера в принципе можно иметь не теговый лимитированный

 

Я поспешил. Думаю лучше иметь абстрактный интерфейс чтения/писания XML, т.к. может быть разные источники XML данных:

- файл, текстовый поток

- выборка из базы данных

- результат работы программы (например, дерево построенное через DOM)

- результат выборки из XML, например через XPath

 

Т.е. алгоритмы получения будут разные, а интерфейс желательно иметь общий. Ну а интерфейс это значит теговый тип.

 

тип. Мне кажется что теговый тип подходит как источник для данных (у меня Text_Stream). Ведь заранее не известно откуда будет чиататься XML, из файла, сокета, памяти. Дима предлагал еще иметь возможность запихивать в парсер данные из того же потока.

 

Чтение из потока (на мой взгляд) - лучший вариант. Именно своей

универсальностью (можно подключить и файл, и соке

 

Какой поток имеется ввиду? Если Ada.Streams, то не представляю, как из него можно ЭФЕКТИВНО получить поток текстовых символов. Хотя он реализуется как поток байт, практически везде, но мы не можем на

это опираться, тк. это не гарантируется в RM. Остается читать по

одному символу, через 'Read, а это *очень* медленно.

 

Я предлагаю определить свой поток, как

 

type Text_Stream is abstract tagged limited null record;

 

procedure Read

(Object : in out Text_Stream;

Text : out String;

Last : out Natural) is abstract;

 

(ну и дла записи наверное нужена procedure Write)

 

чтоб этот поток поставлял 8-ми битные символы. Но здесь кодировка не Latin-1, а та, в которой реально сохранен XML.

 

 

Я бы предложил иметь два интерфейса, String без перекодировки и

Wide_String с уже перекодированными данными. У меня получилось

сделать это в одном generic модуле и не кодировать два раза.

 

String без перекодировки? Такого не бывает. Пока живы non-ASCII char sets (например, EBCDIC) сама Standard.String - результат перекодировки. :(

 

Что-то мы друг друга не понимаем. Вот ты писал:

[2. Хранение строковых данных лучше всего осуществлять без преобразования в какую-либо кодировку.]

 

Я имею ввиду, что если в файле стоит символ в какой-то кодировке Х с кодом 123, то пользователю будет отдан символ Character'Val (123). Пользователь может узнать название текущей кодировки Х и самостоятельно перекодировать этот символ в желаемую. Если пользователю нет нужды разбираться с кодировками, он может просто работать со строкой из таких символов не обращая внимания на кодировку, скопировать там кудато и т.д.

 

А выбор String/Wide_String/Wide_Wide_String/Wide_Wide_Wide_String и т.д. должен осуществляться пользователем библиотеки. В качестве существующих

 

Для этого я и предлагаю иметь разные интерфейсы String/Wide_String.

реализаций можно предложить старый добрый String для char set кодировок и Unicode для всего остального (multibyte, wide). Но со String та же беда останется - она - результат потенциальной перекодировки.

 

 

Я бы сказал наоборот, String идет без перекодировки в том виде в каком получается из Text_Stream. А Wide_String после перекодировки из X в UTF-16.

 

 

Наверное, в моих generic-ах тяжело сходу рабобраться, советую

посмотреть на XML_IO.Base_Readers. Там видно какой интерфейс

предоставляет парсер.

 

Да нет, я думаю, что понял основную идею.

 

Общую иерархию API я предлагаю такую

 

XML_IO

 

XML_IO.Readers

С интерфейсом Reader и функциями Piece_Kind, Next, Name, Text и т.д.

XML_IO.Stream_Readers

С XML парсером, обрабатывающим потоки Text_Stream, реализующим

интерфейс Reader.

 

XML_IO.Wide_Readers

аналогично XML_IO.Readers только строки возвращаются в Wide_String

XML_IO.Stream_Wide_Readers

аналогично XML_IO.Stream_Readers с результатом Wide_String

 

Затем, если кто-то сделает XPath или чтение из DB, результат будет читаться другим типом, реслизующим интерфейс из

XML_IO.Readers/XML_IO.Wide_Readers

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Какой поток имеется ввиду? Если Ada.Streams, то не представляю, как из него можно ЭФЕКТИВНО получить поток текстовых символов. Хотя он реализуется как поток байт, практически везде, но мы не можем на это опираться, тк. это не гарантируется в RM. Остается читать по одному символу, через 'Read, а это *очень* медленно.

 

Ada.Streams это то, что врач прописал :) Попробую объяснить.

 

1. Не критично, что никто не знает, что такое Stream_Element.

Достаточно, что бы он соответствовал одному байту. Если это не так - не страшно, можно просто иметь несколько вариантов читателей.

 

2. Почему Stream_Element, а на Character. Пример:

 

type Character_Code is mod 2**8;

 

procedure To_Character_Code is

new Ada.Unchecked_Conversion (Character, Character_Code);

 

-- Для Latin capital A

 

Put_Line (Integer'Image (Character'Pos ('A')));

Put_Line (Character_Code'Image (To_Character_Code ('A')));

 

Каков будет результат? Implementation dependent!!!

 

На PC:

 

0x41

0x41

 

На IBM S/360-390:

 

0x41

0xC1

 

(Прошу прощения за шестнадцатеричне коды)

 

Вот почему я говорил, что Character - результат перекодировки. И

Character'Read именно это и делает.

 

Вывод: назависимо от кодировки символы и строки можно хранить только как цепочки Stream_Element. Если приложение заинтересуется этими

символами/строками, то производить преобразование в формат, понятный приложению.

 

т.е. для строки получаем:

 

type XML_String is ...;

 

function Stream_Image (Item : XML_String) return Stream_Element_Array;

procedure Set_Encoding (Item : XML_String;

Encoding : Character_Encoding);

 

function Get_Encoding (Item : XML_String) return Character_Encoding;

function To_String (Item : XML_String;

Encoding : Character_Encoding := Default)

return String;

 

function To_Wide_String (Item : XML_String) return Wide_String;

-- Always UTF-16?

 

function To_Wide_Wide_String (Item : XML_String)

return Wide_Wide_String;

-- Always UCS-4 (UTF-32)?

 

Ну и набор подпрограмм для прохода по элементам, вырезания сегмента, вставки/замены и т.д. и т.п.

On Sun, 19 Feb 2006 19:39:15 +0300, Vadim Godunko <vgodunko@...> wrote:

 

Кстати, а вам не кажется, что строки в разных кодировках это должны быть просто разные типы?

 

Тоесть допустим 437 и 866 кодовые наборы можно так и описать String437, Char866 и тп типы.

 

Ну или тип с тегом, тоесть в строке в служебных полях помимо ее длины хранить сразу и код

кодовой таблицы...

 

Ну думаю идея понятна...

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Maxim Reznik wrote:

Я бы предложил иметь два интерфейса, String без перекодировки и

Wide_String с уже перекодированными данными. У меня получилось

сделать это в одном generic модуле и не кодировать два раза.

 

Я ничего не знаю про wide_wide_string. Но работать с xml как со String

без перекодировки - IMHO в корне не правильно. Большинство xml идут в

utf-8 кодировке. И есть у меня опасения, что там можно поймать

спецсимволы типа " < > / во вторых и последующий байтах многобайтовых

символов. По любому придется перекодировать в wide_string перед тем, как

разбирать структуру документа. Врядли кому понадобится библиотека xml,

которая будет таинственным образом глючить, если ей подсовывать xml с

utf-8 или другой многобайтовой кодировкой.

 

Так чтоб IMHO лучше ограничится Wide_String и не возится с generic.

-- Olleg Samoylov

Olleg wrote:

 

Я ничего не знаю про wide_wide_string.

А это новый вид строки в Ada 2005. В два раза "шире", чем Wide_String. Т.е. позволяющий хранить любой символ Unicode в одной единице.

 

Но работать с xml как со String

без перекодировки - IMHO в корне не правильно. Большинство xml идут в

utf-8 кодировке. И есть у меня опасения, что там можно поймать

спецсимволы типа " < > / во вторых и последующий байтах многобайтовых

символов. По любому придется перекодировать в wide_string перед тем, как

разбирать структуру документа. Врядли кому понадобится библиотека xml,

которая будет таинственным образом глючить, если ей подсовывать xml с

utf-8 или другой многобайтовой кодировкой.

 

Структура UTF-8 разрабатывалась таким образом, что бы такого глюка быть не могло в принципе. Но есть другие кодироки, для которых это не верно.

 

Так чтоб IMHO лучше ограничится Wide_String и не возится с generic.

Как я уже писал, преобразование строки XML в Wide_String есть небиективная операция, т.е. после обратного преобразования можно получить совсем не ту строку.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Sun, Feb 19, 2006 at 07:39:15PM +0300, Vadim Godunko wrote:

Maxim Reznik wrote:

 

Какой поток имеется ввиду? Если Ada.Streams, то не представляю, как из него можно ЭФЕКТИВНО получить поток текстовых символов. Хотя он реализуется как поток байт, практически везде, но мы не можем на это опираться, тк. это не гарантируется в RM. Остается читать по одному символу, через 'Read, а это *очень* медленно.

 

Ada.Streams это то, что врач прописал :) Попробую объяснить.

 

1. Не критично, что никто не знает, что такое Stream_Element.

Достаточно, что бы он соответствовал одному байту.

 

Это как раз никак не гарантируется. А вот Character как раз

больше похож на байт, т.к. содержит 256 значений.

Да и XML файл - текстовый файл, его элементы символы, поэтому

и читать его как поток символов - логично, хоть эти символы и

не в Latin-1 кодировке.

 

Если это не так - не страшно, можно просто иметь несколько

вариантов читателей.

 

 

Допустим Stream_Element'Size /= 8. Как быть тогда? Как эти

"варианты читателей" будут реализовывать наш интерфейс?

Не хотелось бы иметь API завязанное на какие-то особенности

компилятора, которые не определяются RM.

 

Например Stream_Element'Size > 8, как пользователь узнает, где

кончается последний символ в результате вызова функции

function Stream_Image (Item : XML_String) return Stream_Element_Array;

(Пусть Stream_Element'Size=16. Stream_Image (X)'Length=4

Сколько символов 7 или 8?)

 

Только компилятор может знать как эфективно преобразовать

Stream_Element_Array в набор символов. Как бы мы не написали наш

парсер, он или будет не переносимым или не эфективным, если

будет читать Stream_Element_Array.

 

2. Почему Stream_Element, а на Character. Пример:

[skip]

На IBM S/360-390:

 

0x41

0xC1

 

Да нам как-то все равно, какой у него код представления, главное, что (в стандартном режиме!) если в файле символ с кодом 123, то

и прочтется он (например при помощи Ada.Text_IO) в код

Character'Val (123). А на нестандартные режимы компияторов

вообще не вижу смысла обращать внимания.

В нестандартном режиме компилятор может делать что

ему захочится и мы там вообще ничего не можем гарантировать.

 

 

Вывод: назависимо от кодировки символы и строки можно хранить только как цепочки Stream_Element. Если приложение заинтересуется этими

символами/строками, то производить преобразование в формат, понятный приложению.

 

 

Напиши эфективное переносимое преобразование из Stream_Element_Array в String и я с тобой соглашусь 8-)

 

 

Ну и набор подпрограмм для прохода по элементам, вырезания сегмента, вставки/замены и т.д. и т.п.

 

 

Вообще не вижу смысла повторно писать то что есть для

String/Wide_String.

 

--

Maxim Reznik

Maxim Reznik wrote:

 

Это как раз никак не гарантируется. А вот Character как раз

больше похож на байт, т.к. содержит 256 значений.

Да и XML файл - текстовый файл, его элементы символы, поэтому

и читать его как поток символов - логично, хоть эти символы и

не в Latin-1 кодировке.

 

Each external parsed entity in an XML document may use a different encoding for its characters. All XML processors must be able to read entities in both the UTF-8 and UTF-16 encodings. The terms "UTF-8" and "UTF-16" in this specification do not apply to character encodings with any other labels, even if the encodings or labels are very similar to UTF-8 or UTF-16.

 

Всё портит UTF-16. Ни о каких байтах и речи идти не может. Правильный алгоритм - поиск в начале файла byte order mark UTF-16, затем попытка найти <?xml в одной из зарегистрированных кодировок, и наконец пытаться трактовать входной поток как UTF-8.

 

Поэтому и поток трактовать нужно в абстрактных единицах, хотя парсеров иметь придётся несколько. Выбор же необходимого комплекта (в зависимости от размера Stream_Element и поддерживаемых кодировок) можно положить на AutoTools и не мучаться.

 

Допустим Stream_Element'Size /= 8. Как быть тогда? Как эти

"варианты читателей" будут реализовывать наш интерфейс?

Не хотелось бы иметь API завязанное на какие-то особенности

компилятора, которые не определяются RM.

 

Для начала - просто не поддерживать.

 

 

На IBM S/360-390:

 

0x41

0xC1

 

Да нам как-то все равно, какой у него код представления, главное,

что (в стандартном режиме!) если в файле символ с кодом 123, то

и прочтется он (например при помощи Ada.Text_IO) в код

Character'Val (123). А на нестандартные режимы компияторов

вообще не вижу смысла обращать внимания.

В нестандартном режиме компилятор может делать что

ему захочится и мы там вообще ничего не можем гарантировать.

 

Это не режим компилятора, это входной поток... И симолы <, >, ', =, " и т.д. ты не найдёшь на их месте... Получается - потребуется перекодировка...

 

 

Напиши эфективное переносимое преобразование из Stream_Element_Array

в String и я с тобой соглашусь 8-)

 

Немного не здесь я грань хочу провести... Но пока думаю как это сделать.

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Sat, Feb 18, 2006 at 03:27:06PM +0300, Sergey I. Rybin wrote:

>Мы с Васей затеяли чужими руками переписать определение ASIS

>в ОО стиле (в виде диплома). С интерфейсами Ады 2005 должно

>бы получиться совсем симпатично, но увы - студенты нынче не те.

>И студентки - тоже :(

 

 

А можно поглядеть на результаты?

 

Мне вот уже по всем статьям и срокам НУЖНО поглядеть на результаты, но - увы и ах! :(((

 

А самому делать (в результате этих мучений я вполне понимаю, как это надо делать) времени нет...

 

 

Не знаю какие цели были поставлены перед студентами, но я у себя

в проекте Gela использовал OO подход чтоб реализовать ASIS.

Т.е. у меня внутри ASIS сделан как иерархия теговых типов, а

сверху на эту объектную дребедень надевается обычный/стандартный

процедурный интерфейс.

 

Некоторое понятие об этой иерархии можно получить по схемкам:

http://www.ten15.org/ada/tree/Base_Element_Node.html

 

Там показаны типы *_Node и их свойства.

 

Причем, после некоторых мытарств, всю иерархию сложил в XML

файл (asis_hier.xml) и генерю пакеты и типы по нему автоматически. Они все однотипные. По этому же XML легко строятся и эти схемки,

и вообще все что нужно, например реализация Asis.Elements.Debug_Image

Парсер строит дерево из этих _Node, а затем вызов, например

Asis.Expressions.Prefix (X), просто вызывает виртуальную функцию

Prefix, которая переопределена для "Appropriate" элементов,

например Slice_Element. Для остальных стреляет функция дающая

Raise_Inapropriate_Elemnt.

 

Если кому интересна тема объектного ASIS-а можем обсудить подробнее.

--

Maxim Reznik

 

Не знаю какие цели были поставлены перед студентами, но я у себя

в проекте Gela использовал OO подход чтоб реализовать ASIS.

 

Это-то я понял. Но у нас задача другая - не реализовать, а ОПРЕДЕЛИТЬ

ASIS в ОО стиле. Ну, Element как начало иерархии, а из него -

производные типы, например, Statement_Element, Declaration_Element

 

Т.е. у меня внутри ASIS сделан как иерархия теговых типов, а

сверху на эту объектную дребедень надевается обычный/стандартный

процедурный интерфейс.

У нас бы получилось ровно наоборот.

 

Парсер строит дерево из этих _Node, а затем вызов, например

Asis.Expressions.Prefix (X), просто вызывает виртуальную функцию

Prefix, которая переопределена для "Appropriate" элементов,

например Slice_Element. Для остальных стреляет функция дающая

Raise_Inapropriate_Elemnt.

 

Тут все сильно зависит от компиляторных потрохов, на которые

ASIS ложится. Мне ОО подход в реализации только мешал бы...

 

Если кому интересна тема объектного ASIS-а можем обсудить подробнее.

 

Мне интересна

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти