Сообщение Re[2]: Ещё насчёт выбора языка посоветуйте от 12.01.2020 23:09
Изменено 12.01.2020 23:43 FDSC
Re[2]: Ещё насчёт выбора языка посоветуйте
Здравствуйте, ·, Вы писали:
FDS>> Есть ли язык программирования, в котором есть следующие фичи:
·>Да любой интерпретируемый или managed, например java
FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
·>java.lang.SecurityManager
Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятор и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
·>Запрет на уровне класса.
Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода.
Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий.
В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
FDS>> 3. Помечать код как неизменяющий состояние программы
·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
FDS>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
·>А чем просто типы не устраивают? class RedString {private final String content;}
Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить.
То есть он должен все производные данные пометить также красной строкой.
Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
FDS>> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
·>Все остальные кастомные состояния контролируются кодом публичных методов.
А если я ошибся или не написал контроль?
В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.
Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
FDS>> Есть ли язык программирования, в котором есть следующие фичи:
·>Да любой интерпретируемый или managed, например java
FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
·>java.lang.SecurityManager
Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятор и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
·>Запрет на уровне класса.
Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода.
Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий.
В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
FDS>> 3. Помечать код как неизменяющий состояние программы
·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
FDS>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
·>А чем просто типы не устраивают? class RedString {private final String content;}
Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить.
То есть он должен все производные данные пометить также красной строкой.
Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
FDS>> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
·>Все остальные кастомные состояния контролируются кодом публичных методов.
А если я ошибся или не написал контроль?
В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.
Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
Re[2]: Ещё насчёт выбора языка посоветуйте
Здравствуйте, ·, Вы писали:
FDS>> Есть ли язык программирования, в котором есть следующие фичи:
·>Да любой интерпретируемый или managed, например java
FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
·>java.lang.SecurityManager
Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
·>Запрет на уровне класса.
Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода.
Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий.
В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
FDS>> 3. Помечать код как неизменяющий состояние программы
·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
FDS>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
·>А чем просто типы не устраивают? class RedString {private final String content;}
Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить.
То есть он должен все производные данные пометить также красной строкой.
Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
FDS>> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
·>Все остальные кастомные состояния контролируются кодом публичных методов.
А если я ошибся или не написал контроль?
В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.
Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
FDS>> Есть ли язык программирования, в котором есть следующие фичи:
·>Да любой интерпретируемый или managed, например java
FDS>> 1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули
·>java.lang.SecurityManager
Нет. Насколько я понимаю, это не то.
Смысл в том, чтобы точно указать, что в этом файле нет вызовов определённых функций.
Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
·>Запрет на уровне класса.
Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
Представьте себе, что я пишу код не в одиночку, а вдвоём. Или кто-то проводит аудит безопасности моего кода.
Ему нужно дать возможность точно убедится, что какие-то функции не влекут за собой определённых действий.
В принципе, это можно делать строковым поиском по шаблону, но это нужно писать отдельный инструмент. И никто не знает, насколько он будет верен.
FDS>> 3. Помечать код как неизменяющий состояние программы
·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
FDS>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
·>А чем просто типы не устраивают? class RedString {private final String content;}
Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить.
То есть он должен все производные данные пометить также красной строкой.
Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
FDS>> 5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
·>Сборщик мусора же. Объекта либо нет, либо к нему доступа нет и деструкторы не нужны.
·>Все остальные кастомные состояния контролируются кодом публичных методов.
А если я ошибся или не написал контроль?
В этом-то и смысл. Я не хочу это делать руками. Я хочу, чтобы это было автоматизированно.
Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.