Ada_Ru форум

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

Type introspection.

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

Сообщения

Alexey Veselovsky
Type introspection.
2013-05-29 23:44:10

Здравствуйте.

Мне нужно иметь возможность в рантайме (но можно в принципе и в

compile-time) получить информацию по типу. Тип допустимо подготовить специальный (то есть скажем унаследованный от кого-то, или там атрибуты ему как-то выкрутить).

Что нужно: нужно знать список полей данного типа (record'a). То есть нужно знать ИМЯ каждого поля и его ТИП (просто списка имен или списка типов полей не достаточно - нужно и то и другое).

Возможно ли?

On Thu, 30 May 2013 03:44:10 +0400, you wrote:

 

Мне нужно иметь возможность в рантайме (но можно в принципе и в

compile-time) получить информацию по типу. Тип допустимо подготовить специальный (то есть скажем унаследованный от кого-то, или там атрибуты ему как-то выкрутить).

 

Что нужно: нужно знать список полей данного типа (record'a). То есть нужно знать ИМЯ каждого поля и его ТИП (просто списка имен или списка типов полей не достаточно - нужно и то и другое).

 

Возможно ли?

 

Я на эту тему написал небольшую статейку:

 

http://ada-programming.blogspot.de/2012/12/type-introspection-in-ada.html

Пример использования здесь:

 

http://www.dmitry-kazakov.de/ada/components.htm#16.2

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Прежде чем писать сюда я ознакомился с этой статьей. В ней нет того что мне нужно - имен полей.

 

On 30.05.2013, at 11:08, "Dmitry A. Kazakov" <alt@dmitry-kazakov.de> wrote:

On Thu, 30 May 2013 11:22:29 +0400, you wrote:

 

В ней нет того что мне нужно - имен полей.

 

А почему нельзя вставить абстрактную примитивную операцию Get_Name в базовый класс? Это стандартный метод в таких случаях.

 

Другой вариант: использование массива ссылок (smart-pointer) с enumeration индексом. Это менее удобно, конечно.

 

Ну, и для больших любителей, конечно, ASIS. Хотя это будет уже совсем далеко от интроспекции.

 

Если не секрет, для чего это потребовалось?

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Alexey Veselovsky wrote:

Здравствуйте.

 

Мне нужно иметь возможность в рантайме (но можно в принципе и в

compile-time) получить информацию по типу. Тип допустимо подготовить

специальный (то есть скажем унаследованный от кого-то, или там атрибуты

ему как-то выкрутить).

 

Что нужно: нужно знать список полей данного типа (record'a). То есть

нужно знать ИМЯ каждого поля и его ТИП (просто списка имен или списка

типов полей не достаточно - нужно и то и другое).

 

Возможно ли?

 

Старая добрая задача из области program reflection, до сих пор

не решенная...

 

С ходу два тупых решения:

 

1. а определить для этого типа операцию, выдающую нужную

информацию! И переопределят ее при определении потомков.

 

2. здесь так и просится анализ кода при помощи ASIS. Но это,

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

а во время выполнения информацию получать. Но вот с помощью

ASIS нетрудно написать генератор для указанного в п.1

 

Вопросы:

 

1. А оно вообще зачем?

2. Что значит - знать тип компоненты? В каком виде предполагается

получать информацию о типе?

On 2013-05-30 14:22, Alexey Veselovsky wrote:

Прежде чем писать сюда я ознакомился с этой статьей. В ней нет того что мне нужно - имен полей.

У меня смутные подозрения, что выбран не совсем верный путь решения какой то конкретной задачи.

Рантайм уже ничего не знает про имена полей записи. Именя полей рантайму известны только на этапе компиляции,

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

укажешь это линкеру и компиляторы.

Ну, и для больших любителей, конечно, ASIS. Хотя это будет уже совсем далеко от интроспекции.

Ну, это как сказать на самом деле. У нас много лет бродит идейка как подключить ASIS к задаче интроспекции. Общая идея такова: добавить применимый к чему угодно реализационно-зависимый атрибут (назовем его условно 'Element), который возвращает результат типа ASIS.Element, соответствующий данной языковой сущности. А вот дальнейший разбор уже непосредственно в самой программе. При наличии такого механизма запрошенное в исходном письме элементарно достигается...

ВФ

On Thu, 30 May 2013 21:31:36 +0200, you wrote:

 

Ну, и для больших любителей, конечно, ASIS. Хотя это будет уже совсем далеко от интроспекции.

 

Ну, это как сказать на самом деле. У нас много лет бродит идейка как подключить ASIS к задаче интроспекции. Общая идея такова: добавить применимый к чему угодно реализационно-зависимый атрибут (назовем его условно 'Element), который возвращает результат типа ASIS.Element, соответствующий данной языковой сущности.

 

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

 

Вопрос в обратном направлении. Для рефлексии нужно из описания получить сам объект, т.е., скажем, тип поля записи.

 

Я думаю, что все же без ASIS это было бы проще сделать. Ключевой вопрос - как избежать ситуации когда типы и операции становятся гражданами "первого сорта". Понятно, что это разрушило бы строгую статическую типизацию языка.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Vasiliy Fofanov wrote:

 

Ну, это как сказать на самом деле. У нас много лет бродит идейка как

подключить ASIS к задаче интроспекции. Общая идея такова: добавить

применимый к чему угодно реализационно-зависимый атрибут (назовем его

условно 'Element), который возвращает результат типа ASIS.Element,

соответствующий данной языковой сущности. А вот дальнейший разбор уже

непосредственно в самой программе. При наличии такого механизма

запрошенное в исходном письме элементарно достигается...

 

 

Только и того, что это требует генерации деревьев для ASIS'а, и совершенно непонятно:

 

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

2. куда их девать (а они места занимают изрядно) и кто будет

убирать ненужные?

Только и того, что это требует генерации деревьев для ASIS'а, и совершенно непонятно:

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

Там - никто, они будут созданы в процессе компиляции и логически будут частью исполняемого окружения.

2. куда их девать (а они места занимают изрядно) и кто будет

убирать ненужные?

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

ВФ

Вопрос в обратном направлении. Для рефлексии нужно из описания получить сам объект, т.е., скажем, тип поля записи.

В каком смысле, "в обратном направлении"?

Я думаю, что все же без ASIS это было бы проще сделать.

Конечно. Но это будет уже не Ада. А идея подключиться через нестандартный атрибут - сохраняет сам язык в целости и сохранности.

ВФ

Vasiliy Fofanov wrote:

Только и того, что это требует генерации деревьев для ASIS'а, и совершенно непонятно:

 

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

 

Там - никто, они будут созданы в процессе компиляции и логически будут частью исполняемого окружения.

 

2. куда их девать (а они места занимают изрядно) и кто будет убирать ненужные?

 

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

 

 

Вспомнился старый неприличный анекдот:

 

"Possible... But very expensive!"

Вспомнился старый неприличный анекдот:

"Possible... But very expensive!"

Ну дык за идею-то - ничего не жалко :) Не забывайте что деревья занимают такой чудовищный размер поскольку пакуются алгоритмом RLE. Это мягко говоря не самый эффективный алгоритм сжатия из известных человечеству ;) Так что приспичит если - резервы есть.

Но - таки да, very expensive и к тому же nobody cares, почему идея и остается многие годы не более чем идеей :) Даже на публикацию идеи в журнальчике сил нет :)

ВФ

On Fri, 31 May 2013 11:26:16 +0200, you wrote:

 

Вопрос в обратном направлении. Для рефлексии нужно из описания получить сам объект, т.е., скажем, тип поля записи.

 

В каком смысле, "в обратном направлении"?

 

Из описания. Вы имеете тип записи T. Из него получаете описание T. Из описания достаете описание 5-го по-порядку поля. А из него его тип F. И декларируете переменную X типа F.

 

Я думаю, что все же без ASIS это было бы проще сделать.

 

Конечно. Но это будет уже не Ада. А идея подключиться через нестандартный атрибут - сохраняет сам язык в целости и сохранности.

 

Это любимая отмазка ARG. Любая новая версия "не Ада", если так

рассматривать. А если нет, то в чем именно это не будет Адой?

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Из описания. Вы имеете тип записи T. Из него получаете описание T. Из описания достаете описание 5-го по-порядку поля. А из него его тип F. И декларируете переменную X типа F.

Не, такое конечно не получится. АСИС естественно может дать только статическую интроспекцию. Динамической модификации кода получить не сможем.

Конечно. Но это будет уже не Ада. А идея подключиться через нестандартный атрибут - сохраняет сам язык в целости и сохранности.

Это любимая отмазка ARG.

Ну а что ж вы хотели :)

Любая новая версия "не Ада", если так рассматривать.

Естественно. Но мое-то предложение как раз *не требует* новой версии языка. Всего-то нового атрибута. Это разрешено.

On Fri, 31 May 2013 14:23:53 +0200, you wrote:

 

Из описания. Вы имеете тип записи T. Из него получаете описание T. Из описания достаете описание 5-го по-порядку поля. А из него его тип F. И декларируете переменную X типа F.

 

Не, такое конечно не получится. АСИС естественно может дать только статическую интроспекцию. Динамической модификации кода получить не сможем.

 

Этого и не требуется. Хватило бы что-то вроде уже имеющегося generic constructor-а.

Любая новая версия "не Ада", если так рассматривать.

 

Естественно. Но мое-то предложение как раз *не требует* новой версии языка. Всего-то нового атрибута. Это разрешено.

 

Так в атрибут можно упаковать все что угодно. Например:

 

X'ASIS_Type

 

Всех делОв. Ада имеет атрибуты возвращающие типы. Ну можно потребовать статичности X. Что не такая уж проблема:

 

X'ASIS_Type (выражение)'ASIS_Type (выражение)'ASIS_Type (выражение)...

даст кривую, но навигацию по дереву. Выражение выбирает путь в узле.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Так в атрибут можно упаковать все что угодно. Например:

X'ASIS_Type

Эээ и что это означает? Что такое ASIS_Type?

Конечно. Но это будет уже не Ада. А идея подключиться через нестандартный

атрибут - сохраняет сам язык в целости и сохранности.

>

Это любимая отмазка ARG. Любая новая версия "не Ада", если так

рассматривать. А если нет, то в чем именно это не будет Адой?

Кстати, а какой сейчас смысл в стандарте, коль дефакто остался ровно один компилятор современной Ады, а новых компиляторов, соответствующих стандарту, не появится из за объема работы? Такое ощущение, что работа по старинке, через стандарт, только тормозит процесс развития языка.

On Sat, 1 Jun 2013 02:02:42 +0200, you wrote:

 

Так в атрибут можно упаковать все что угодно. Например:

 

X'ASIS_Type

 

Эээ и что это означает? Что такое ASIS_Type?

 

Тип разумеется. Так же как в S'Base или T'Class. X - описание.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Sat, 1 Jun 2013 06:03:54 +0400, you wrote:

 

Конечно. Но это будет уже не Ада. А идея подключиться через нестандартный

 

атрибут - сохраняет сам язык в целости и сохранности.

 

Это любимая отмазка ARG. Любая новая версия "не Ада", если так

рассматривать. А если нет, то в чем именно это не будет Адой?

 

Кстати, а какой сейчас смысл в стандарте, коль дефакто остался ровно один компилятор современной Ады, а новых компиляторов, соответствующих стандарту, не появится из за объема работы? Такое ощущение, что работа по старинке, через стандарт, только тормозит процесс развития языка.

 

Да ладно Вам, даже C++ имеет теперь стандарт. Вопрос в том каков стандарт и каковы цели его разработчиков, т.е. ARG-a. А так, каждые 5 лет, как с куста, новая Ада.

 

Размер языка - больная тема. Но пока ARG идет по пути нагромождения заплаток это не изменится.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

Да ладно Вам, даже C++ имеет теперь стандарт. Вопрос в том каков стандарт и

каковы цели его разработчиков, т.е. ARG-a. А так, каждые 5 лет, как с

куста, новая Ада.

 

Размер языка - больная тема. Но пока ARG идет по пути нагромождения

заплаток это не изменится.

 

Здесь надо понимать 2 вещи:

 

1. По правилам ISO, любой стандарт на информационную технологию раз в 10

лет подлежит обязательной ревизии. Вариант "все устраивает, ничего не

меняем" в качестве ревизии тоже годится, но он должен пройти через

формальную ISO-шную процедуру. С этой точки зрения стандарт Ады -

единственный на данный момент живой стандарт на язык программирования.

 

Но вот какой от этого толк?... Чем дальше - тем меньше я это понимаю

 

2. Развитие Ады осуществляется по сути AdaCore. А AdaCore, как контора

коммерческая идет на поводу у пользователей. Даже не на поводу - на поводке.

Причем - на коротком. Увы.

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

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