Добрый день!
В конце письма приведены мои заметки по синтаксису языка описания интерфеса.
Всё же подумав, я склонился к идее разработки упрощенного языка описания интерфейса вместо использования ASIS. (Идея ASIS ни в коем разе не отменяется - её проще реализовать; а вот на некий язык не помешает для понимания того, чего мы хотим достичь).
Язык описания интерфейса ядра приложения с интерфейсом пользователя
-------------------------------------------------------------------
Язык предназначен для описания элементов интерфейса между ядром приложения и
реализацией интрефейса пользователя.
Основной задачей описания интерфейса является проведение "границы" между ядром
приложения и реализацией интерфейса пользователя. Таким образом, язык должен
однозначно указать элементы, доступные обоим сторонам.
Из ядра проиложения язык позволяет импортировать следующие элементы:
- типы данных (кроме задач и защищенных объектов);
- операции над типами данных;
- подпрограммы.
Для ядра приложения язык предоставляет возможность описания:
- компонентов интерфейса пользователя;
- атрибутов компонентов;
- операций компонентов;
- фабрик для создания компонентов.
Описание синтаксиса языка
-------------------------
Предлагается сделать язык описания Ada подобным для устранения шока от C
подобных языков у рядовых Ada программистов. :)
<unit> ::= <context_clause>* <interface_declaration>
<context_clause> := <with_context_clause>
| <with_interface_context_clause>
<with_context_clause> ::= with <ada_unit_name>;
Подключение Ada модуля. Все элементы модуля могут быть использованы при
описании интерфейса.
<with_interface_context_clause> ::= with interface <module_name>;
Подключение другого описания интерфейса.
<interface_declaration> ::=
interface <interface_name> is
<declaration>*
end <interface_name>;
<declaration> ::= <component_declaration>*
| <component_derived_declaration>*
| <type_declaration>
<type_declaration> ::=
Имеет смысл взять все основные виды типов из языка Ada равно как и синтаксис
их объявления. Однозначно исключение составляют задачи и защищенные объекты.
XXX Вопрос о наличии необходимости объявления типов ещё предстоит обсудить.
XXX Vadim Лично мне кажется, что это излишне. Типы должны либо импортироваться
XXX либо будут являться сугубо внутренними для реализации.
<component_declaration> ::=
component <component_name> is
???
end component;
<component_derived_declaration> ::=
component <component_name> is new <component_name> with
???
end component;
<attribute_declaration> ::=
attribute <attrbiute_name> is <type_name> ;
| readonly attribute <attribute_name> is <type_name> ;
<procedure_declaration> ::=
procedure <procedure_name> <subprogram_profile> ;
<function_declaration> ::=
function <function_name> <subprogram_profile>
return <type_name>;
Пример
------
with Ada.Strings.Unbounded;
interface My is
component Message_Box is
attribute Message is Ada.Strings.Unbounded.Unbounded_String;
procedure Show;
procedure Hide;
end component;
end My;
with interface My;
interface My_Super is
component Super_Message_Box is new My.Message_Box with
attribute Hint is String;
end component;
end My_Super;
Что из этого должно получиться
------------------------------
------------------------------------------------------------------------------
with Ada.Strings.Unbounded;
with GUIA.Components;
package My is
type Message_Box is new GUIA.Components.Component with null record;
function Get_Message (Self : in Message_Box)
return Ada.Strings.Unbounded.Unbounded_String;
procedure Set_Message (Self : in Message_Box;
Value : in Ada.Strings.Unbounded.Unbounded_String);
procedure Show (Self : in Message_Box);
procedure Hide (Self : in Message_Box);
end My;
------------------------------------------------------------------------------
with GUIA.Components.Implementation;
package My.Implementation is
type Message_Box_Implementation is
new GUIA.Components.Implementation.Component_Implementation with private;
function Get_Message (Self : access Message_Box_Implementation)
return Ada.Strings.Unbounded.Unbounded_String;
procedure Set_Message (Self : access Message_Box_Implementation;
Value : in Ada.Strings.Unbounded.Unbounded_String);
procedure Show (Self : access Message_Box_Implementation);
procedure Hide (Self : access Message_Box_Implementation);
private
type Message_Box_Implementation is
new GUIA.Components.Implementation.Component_Implementation with
record
-- Сюда попадут переменные, созданные по описанию реализации.
null;
end record;
end My.Implementation;
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
hi,
teplouhov@... wrote:
On Wed, 17 Aug 2005 13:43:25 +0400, Vadim Godunko <godunko@...> wrote:
...
Язык описания интерфейса ядра приложения с интерфейсом пользователя
может все-же не язык, а что-то вроде описания проекта(ну тоже правда
на каком-то спецязыке :) )
Подобным образом можно бы легко определить неизменяемую структуру
и всякую всячину наподобии ключей компилятора и тп.
Все остальное все-же думаю лучше свести к данным.
(если базу удобнее писать в тексте, можно опционально
сделать транслятор, но на выходе все-же стандартная
структура данных с известной постоянной структурой.
А вот в языке можно менять и структуры или переадресовать
на что-то другое...)
хм... Вообще, идея - отделить логику программы от интерфейса
не нова. Насколько помню, МелкоМягкие для этого выдумали
такую весТЧь как ресурсы, со своим ресурс-компилятором
(кажись, оно обзывалось как "rc").
Борланды для своих Делфей изобрели "файлы форм"
с интерактивным редактором форм. Чтение/запись файла-формы
осуществляется через поток используя полиморфность ООП.
Что лучше, на вскидку сказать сложно, но реализация идей
любого из этих подходов на Аде - возможна.
Alex
Oleksandr Havva wrote:
хм... Вообще, идея - отделить логику программы от интерфейса
не нова. Насколько помню, МелкоМягкие для этого выдумали
такую весТЧь как ресурсы, со своим ресурс-компилятором
(кажись, оно обзывалось как "rc").
Борланды для своих Делфей изобрели "файлы форм"
с интерактивным редактором форм. Чтение/запись файла-формы
осуществляется через поток используя полиморфность ООП.
Что лучше, на вскидку сказать сложно, но реализация идей
любого из этих подходов на Аде - возможна.
Я уже говорил, что любой toolkit позволяет это сделать. Только
использовать это как правило можно только в проектах уровня диссертации
- написал, защитил, и послал всех на фиг.
Идея же здесь - произвести указанное деление на другом месте, а именно, обеспечить отсутствие в коде ядра приложения каких-либо зависимостей от используемого toolkit-а.
Получается, что (в идеале) у нас есть программа и набор библиотек динамиченской загрузки (для каждого toolkit-а по одной). При запуске загружается одна из и используется. :)
PS. Не бить - знаю, что WinAPI в UNIX не прокатит. Но вот NCurses с command line или Gtk или Qt или Motif - запросто.
--
Vadim Godunko
hi,
Vadim Godunko wrote:
Идея же здесь - произвести указанное деление на другом месте, а именно,
обеспечить отсутствие в коде ядра приложения каких-либо зависимостей от
используемого toolkit-а.
Получается, что (в идеале) у нас есть программа и набор библиотек
динамиченской загрузки (для каждого toolkit-а по одной). При запуске
загружается одна из и используется. :)
Эта идея тоже не нова ;-)
На моей памяти первый раз подобные замыслы были озвучены
группой разработчиков Lazarus-а. Lazarus - это такая себе
Delphy-образная RAD, только изначально "заточена" под
компилятор Freee Pascal.
Сейчас уже не вспомню в чем заключалась суть ихнего решения, но...
в результате они "паламались"... и в качестве основной GUI-библиотеки
"засели" на GTK. Правда на системном уровне механизмы "подмены"
низлежащей GUI-библиотеки - остались.
Alex
On Wed, 17 Aug 2005 13:43:25 +0400, Vadim Godunko <godunko@...> wrote:
...
Язык описания интерфейса ядра приложения с интерфейсом пользователя
может все-же не язык, а что-то вроде описания проекта(ну тоже правда
на каком-то спецязыке :) )
Подобным образом можно бы легко определить неизменяемую структуру
и всякую всячину наподобии ключей компилятора и тп.
Все остальное все-же думаю лучше свести к данным.
(если базу удобнее писать в тексте, можно опционально
сделать транслятор, но на выходе все-же стандартная
структура данных с известной постоянной структурой.
А вот в языке можно менять и структуры или переадресовать
на что-то другое...)
...
Из ядра проиложения язык позволяет импортировать следующие элементы:
это уже наверно не язык, а программа-грабилка ;)
...
Описание синтаксиса языка
-------------------------
Предлагается сделать язык описания Ada подобным для устранения шока от C
подобных языков у рядовых Ada программистов. :)
ну синтаксис можно описать на чем-то вроде yacc и сделать несколько
вариантов - хоть Ада, хоть Ц, хоть ваще что-то новое...
Vladimir
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Hello Alex,
Wednesday, August 17, 2005, 6:44:20 PM, you wrote:
hi,
Vadim Godunko wrote:
>Идея же здесь - произвести указанное деление на другом месте, а именно, >обеспечить отсутствие в коде ядра приложения каких-либо зависимостей от >используемого toolkit-а.
>Получается, что (в идеале) у нас есть программа и набор библиотек >динамиченской загрузки (для каждого toolkit-а по одной). При запуске >загружается одна из и используется. :)
Эта идея тоже не нова ;-)
На моей памяти первый раз подобные замыслы были озвучены
группой разработчиков Lazarus-а. Lazarus - это такая себе
Delphy-образная RAD, только изначально "заточена" под
компилятор Freee Pascal.
>...
Народ, а Lazarus под Аду заточить не удастся? Неплохая IDE, если
глядеть на скриншоты :)
--
Best regards,
Vladyslav
On Wed, Aug 17, 2005 at 01:43:25PM +0400, Vadim Godunko wrote:
Язык описания интерфейса ядра приложения с интерфейсом пользователя -------------------------------------------------------------------
А что поменялось по сравнению с описанием в Аде?
Я вижу только, что добавилось наследование.
А оно вообще нужно? Может какой-то пример
с наследованием помог бы...
--
Maxim Reznik
On Wed, 17 Aug 2005 23:12:16 +0300, Maxim Reznik <yeo@...> wrote:
On Wed, Aug 17, 2005 at 01:43:25PM +0400, Vadim Godunko wrote:
Язык описания интерфейса ядра приложения с интерфейсом пользователя
-------------------------------------------------------------------
А что поменялось по сравнению с описанием в Аде?
Я вижу только, что добавилось наследование.
А оно вообще нужно?
что-то мне так кажется что не очень :)
Как и вообще все ООП, точнее то что сотворили
из такой простой идеи...
Может какой-то пример с наследованием помог бы...
Только как пример как не надо делать :)
Например, если мы хотим чтобы по описанию record
сразу можно было сделать и морду для ее ввода,
можно бы строковые комментарии описать в другом
объекте, куда саму запиcь наследовать...
Кстати, а что там у наc насчет debug info?
Ведь это уже все должно быть готовое!
Тем более имея исходники всего можно 99% использовать
готового...
Vladimir
PS У меня вообще есть идея что все внутренние
структуры данных должны быть всегда доступны
для просмотра чем-то вроде отладчика.
Да и вообще удобнее - например, можно будет
часть координат ввести мышой, а потом переключиться
на режим редактирования внутренних данных и ввести
в виде чисел, подправить, или просто посмотреть
что там твориться...
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
hi,
Vladyslav Kozlovskyy wrote:
Народ, а Lazarus под Аду заточить не удастся? Неплохая IDE, если
глядеть на скриншоты :)
это врядли, там паскаль слишком "глубоко зарыт", особенно в части отладки
Alex
Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти