Ada_Ru форум

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

Язык описания интерфейса - вариант 1

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

Сообщения

Vadim Godunko
Язык описания интерфейса - вариант 1
2005-08-17 09:43:25

Добрый день!

 

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

 

Всё же подумав, я склонился к идее разработки упрощенного языка описания интерфейса вместо использования 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

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

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