OberonCore

viewtopic.php?f=22&t=6482&p=109508#p109503
В рефлексии заключены могучие возможности, поэтому она решает многие задачи и поэтому же её не стоит использовать. За редким исключением.

Смотря где. Вроде бы, это одна из основных фишек Lisp.

Сейчас наметилась несколько иная тенденция. Рефлексия времени исполнения признана нежелательной и ей противопоставлятся рефлексия времени трансляции.
Рефлексия времени исполнения мешает глубокой переработке программы, а во многих случаях она желательна. Например, в мире Java широко используются обфускаторы как для защиты от анализа, так и для оптимизации, и без тонкой настройки мало-мальски большая программа не заработает или заработает не так, как надо. Но всё больше новых библиотек для Java или новых версий старых библиотек не требуют настройки. Теперь разработчики предпочитают аннотации и кодогенерацию во время трансляции. Также это позволяет серьёзно оптимизировать код, так как рефлексия во время исполнения требует значительных ресурсов по сравнению с прямым кодом.

Рефлексия нужна для отладки. Кому не нужна, тот не использует. Кому нужна - тот не обсуждает.


Да, поговорка про то, что "любая достаточно сложная программа на С++ содержит половину кривой реализации лиспа" верна и в случае java.

И самое главное - не зависимо от чьего-либо мнения о нужности или ненужности, в моём форке A2 рефлексия будет, и это ближайший пункт плана. Потому что без неё отлаживать сколько-нибудь сложные, написанные не мной и недокументированные вещи (типа TFPET) - это просто ад. Человеку, который ещё не забыл ощущения от работы в лиспе, это очень тяжело переносить, и только понимание временности данного состояния выручает.

Хотя кстати да. Делать сериализацию/десереализацию можно и через кодогенерацию в статике. Только вот это требует дополнительной инфраструктуры разработчика. А через рефлексию это делается проще. Возможно, что имеет смысл наложить ограничения на рефлексию и делать с помощью неё только то, что можно было бы сделать и чисто статически. А в случае, если это нельзя сделать статически, подумать, не зашли ли мы куда-то не туда, или ограничить такую практику теми случаями, когда это действительно нужно (например, интерпретатор с автодополнением вводимых команд без рефлексии никак не организовать).

Рефлексия для отладки есть и в Си, но разве речь о такой её разновидности? На ней ведь никто всерьёз не решает задачи, выходящие за пределы отладки.

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

Вообще, внедрение такой рефлексии в A2, на мой взгляд, похоже на трагикомедию, потому что является отстающим прыжком вслед за мейнстримом туда, откуда мейнстрим уже стремится выпрыгнуть.

Красивая фраза, не более. Где хоть какое-то подтверждение, что мейнстрим куда-то там собирается выпрыгнуть, в частности, с рефлексией?

И вообще, если там где-то что-то протекает в мире Ц/Ц++, не надо экстраполировать это протекание на все языки.

Пишите на нормальных языках, на Delphi и Go, например, и будете в сухости и комфорте И рефлексия в них почему-то есть.

Мы тянемся за лидером развития, т.е за Blackbox, в котором такая возможность в окне TRAP есть

В этом плане все Обероны "протекают". У всех Оберонов окно TRAP богатое
Вот, по-моему, такое богатство, это как-раз плюс, а не минус.

Подтверждение, в смысле научной работы по тенденциям в mainstream? Это результат наблюдения, основанный на перелопачивании большого количества библиотек. Annotation processor в Java, отчасти, для того и нужно, чтобы поменьше лезть в рефлексию во время исполнения и это работает. Отменить что-либо полностью из-за наследия, в том числе идейного, невозможно, но тенденция достаточно очевидная.

Абстракции из-за рефлексии во время исполнения протекают вне зависимости от "нормальности" языка. Это можно попытаться ограничить, но тогда она потеряет привлекательность для сторонников использования рефлексии для решения обыденных задач.

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

Т.е. больше уход в сторону аннотаций? Но аннотации тоже пишутся в объектный файл? В чём тогда принципиальные отличия с Активным Обероном? Аннотаций нет, но компилятор генерирует информацию о типах и складывает в отдельный байтовый массив, находящийся в объектном файле. При желании этот байтовый массив можно из объектного файла вообще выбросить и никакой рефлексии не будет. В чём тогда проблема? В желании напустить туману?

Ну, так пишите на С, раз там всерьёз не используют. Нам один преподаватель говорил "никогда не используйте в С указатели". И я его прекрасно понимаю.
Ещё раз напоминаю, не экстраполируйте "общепринятые" проблемы С на другие языки.

ЗЫ. Но легко сказать, не используйте указатели. Они же, сволочи, везде выпирают. Уродские сишные "массивы" чего стоят.

Да зря пытаться решать проблемы информ. безопасности (т.е. защиты не от неправильного использования, а от злоумышленного вмешательства) в одной адресном пространстве, языковыми средствами.. Тут таки изоляция процессов. Т.е. модель типа Minix 3 + Oberon в каждом процессе.

Иначе потери в гибкости (за счёт лишения возможностей той же рефлексии) большие, усложнение защитных средств тоже, а гарантий всё равно нет (верифицировать всю семантику на то, что она не "подтекает" - упаришься.. Как уязвимость WITH на тему изменить указатель из тела WITH - и крэшнуть память).

Для супер-оптимизаций и выкидывания неиспользуемого кода да, стараются ограничить использование рефлексии (как в Dart, где в упакованный JS идут только реально использующиеся функции и типы). Но тут уже надо возлагать на разработчика ответственность: использует что-то динамически - пусть добавляет зависимость в конфиг для учёта сборщиком...

Отказ от рефлексии - архитектурно шаг назад.

Преимущества - можно делать неявные вещи.
Недостаток - можно делать неявные вещи.

Например, в джяве фреймворк Спрынг основан на прокси-классах, то есть рефлексией анализируется ваш класс (по-нашенски - модуль), все интерфейсные методы фиксируются и прямо в рантайме формируется (на уровне машкода, да, вот какой прогрэсс) класс-обёртка с какими-то дополнительными функциями, например, транзакционность до первого исключения. Клиентский код как работал, так и работает, а класс по факту уже другой. Вы должны это предполагать, надеяться на это. Проверять это. Но клиентский код всего этого не предполагает и когда, например, он попытается стандартными средствами сохранить состояние этого класса в JSON, тут и наступит разочарование. Дальше олухи одумались и ввели понятие POJO, которые типа не принято обёртывать, они типа честные классы и объекты.

Так что как всегда, придумали дурь, а теперь с этим живут.

Во-первых, доступно только то, что явно помечено, а не всё подряд (призываю Валерия Лаптева ), а во-вторых, аннотации могут быть времени трансляции, то есть, во время исполнения доступ к ним не получить.

Завязав всё на решениях на основе рефлексии, ни желания ни возможности выбросить эти данные не будет.

Верно, но с точностью до наоборот - нет большой пользы от изоляции процессов, если протекают абстракции на уровне процесса. Если процесс получает данные из недоверенного источника, недостаточно хорошо их проверяет, формирует на их основе запрос в рефлексию, командную оболочку, базу данных, к процессору и т.д.(богатую программную среду), то он предоставляет несанкционированный доступ вовне вне зависимости от наличия богатой архитектурной изоляции. Почему вообще компьютерные системы взламываются? Разве компьютеры не изолированны друг от друга аппаратно?

А Вы точно не можете решить свои архитектурные задачи на знаниях о программе на этапе трансляции?

Наверное, лучше говорить не о полном отказе, а о необходимости ограничения такой возможности. В Java с 9 версии уже так просто не помахаешь рефлекшеном из-за внедрения модулей.

И неплохо бы предметно. Т.е. для таких-то случаев рефлексию хорошо использовать, а для каких-то - нет. Потому что данная тема изначально сформулирована несколько манипулятивно. Допустим, даже рефлексия почти всегда - это зло. А что делать в остальных случаях? Полезность отладочной печати никто не оспаривал, и её очень естественно можно сделать через рефлексию. Более того, в случае параметра ANY её никак иначе сделать и невозможно, потому что нужно как-то перейти от типа ANY к конкретному типу и это можно сделать только за счёт RTTI. Значит, в целом рефлексия нужна.

Если тут происходит попытка привести кого-то к выводу, что раз рефлексия почти никогда не нужна, то она и совсем не нужна, то эта попытка обречена на провал. Если цель иная, то было бы неплохо бы, чтобы автор темы её сформулировал. Также нет никакого смысла осуждать тип ANY - он уже есть в A2 и довольно широко используется, является ли он безопасным или нет.

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

Так статистика известна. Для системного уровня >95% (как бы не 98?) - атака на переполнение буфера.

Или аналог для динамических скриптов: всякие атаки на инъекцию.

Остальное решается принципов минимализма: компактные логические протоколы и API. Чтобы лезть по пришедшему из сети имени тупо "рефлексировать" - ну это, во-первых, редко сама по себе такая мысль придёт, во-вторых, и проверить в таком случае можно.