Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Вы здесь » Ремесло программиста » Валентина » Проверка корректности имени системы

Проверка корректности имени системы

Страница: 1

Сообщений 1 страница 10 из 10

1

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

При создании системы необходимы определенные правила.
1. Система не должна получить имя уже существующей системы (для того, чтобы была возможность их различать)
2. Имя системы должно удовлетворять некоторым условиям. Поскольку язык немного отличается от большинства остальных эти правила следует рассматривать отдельно. Итак, пока я вижу два условия:
     - система не должна содержать в себе пробела, символа табуляции (предлагайте еще знаки);
     - система не должна начинаться с цифры (из-за возможного использования в арифметических выражениях - данный вопрос пока проработан слабо).

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

Наверно здесь же нужно рассматривать вопрос имен пространств. По умолчанию все грузится в одну ветвь Вселенной (напрямую не доступную программисту). Естественно возможен конфликт имен. И чем больше модулей тем больше вероятности конфликта систем с одинаковыми именами. Я могу их грузить в разные ветви вместо одной (например по именам файлов), но вопрос доступа к системам с одинаковыми имена в разных модулях остается открытым. Может просто все имена из внешних модулей обязательно указывать вместе с именем модуля?

2

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25
utkin написал(а):

1. Система не должна получить имя уже существующей системы (для того, чтобы была возможность их различать)

Список систем при добавлении проверять. При конфликте разносить в разные пространства или переменные окружения. Минимум достаточно по разным папкам.

А вообще у вас функции это системы. Значит пересечения неизбежны. Так как часы ходят и животные ходят, а системы разные. И даже надсистемы у них разные.

utkin написал(а):

Может просто все имена из внешних модулей обязательно указывать вместе с именем модуля?

Это неудобна. Будет этажерка аля
Global.Windows.Consol.IOSystem.Teletype.Write.WriteInt

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

3

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

А вообще у вас функции это системы. Значит пересечения неизбежны. Так как часы ходят и животные ходят, а системы разные. И даже надсистемы у них разные.

Да, нужен какой-то цивилизованный механизм.

Вообще у меня есть наброски на этот счёт, но они выходят за рамки простого синтаксиса.

Поделитесь - вдруг понравится и я украду Вашу идею :).

4

  • Автор: ВежливыйЛис
  • Активный участник
  • ВежливыйЛис
  • Сообщений: 408
  • Провел на форуме:
    2 дня 13 часов
  • Последний визит:
    2021-07-13 18:36:29
utkin написал(а):

я украду Вашу идею :)

"Я куплю лицензию на Вашу идею," - вот как это должно звучать в такой  цивилизованной стране как Россия.

Отредактировано ВежливыйЛис (2017-10-03 04:30:07)

5

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

"Я куплю лицензию на Вашу идею," - вот как это должно звучать в такой  цивилизованной стране как Россия.

Да ладно. Идея не стоит ничего. Лицензии вводятся на реализацию идеи. А это большая разница.

6

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25

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

К примеру при вызове метода класса в качестве параметра передаётся указатель на класс. Self, this -  черещ регистр ebx.

Так вот положение в иерархие это тоже общие данные. Доступные на запись надсистеме. (Нужен атрибуиный механизм защиты как у файлов, возможно ACL)

Во время исполнения программы в общием случае настраивает иерархию модулей, сисием функций.
Подобно тому как в unix сделана настройка окружения. Я могу в юнексе запустить программу в нужном окружении. Создать папку opt/myenv/bin
Прописать её в переменную path.
Даже можно сменить корень и сделать потдельного суперпользователя.
Всё это общие данные. А иерорхическая структура подобна vfs - такой как /proc.

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

7

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Пока я слабо представляю связь написанного с конфликтом имен систем при импорте их из внешних модулей. Скажу даже больше - вообще не представляю.
Половина из того что Вы пишите и так решается иерархией автоматически. Например нельзя взять одну систему произвольно, а только в соответствии с иерархией. Это и есть окружение (допустим подсистема не может обратиться к надсистеме или вообще к соседней ветви, максимум это свои подсистемы). А подсистема не может обратиться на два уровня ниже, если там не публичная часть и т.д. Разграничение доступа и так есть в модели вычислений.
Вопрос стоит в том, как обращаться к описаниям систем. Ну например, есть внешний модуль Контейнеры и внешний модуль Абстрактные_типы_данных. Оба имеют описание системы Список. Но эти системы различны (разный интерфейс, по-разному работают).
Сейчас мы внутри нашей системы начинаем объявлять подсистемы среди которых есть какой-нибудь Список_контактов, который наследуется от Список. Ну это же классическая проблема. Как цивилизованно разграничить доступ? Как узнать какой список требуется? Как узнать какой список будет выбран?
При командной разработки Вы можете не знать какие зависимости потянут остальные игроки. И естественно вполне вероятно совпадение имен.

8

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25
utkin написал(а):

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

Это всё решает иерархия автоматически. ;)
Есть программист и он описывает в каких рамках его кусок должен работать.  Указывает ссылки на другие системы которые он ожидает увидеть - обычное дело.
Если имена одинаковые, а интерфейсы разные то программисту надо разложить код по разным "папкам".
Разумеется делает это программист вышестоящей системы.

9

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Это всё решает иерархия автоматически.

Я так и написал. Вопрос приведет к тому, что имя внешнего модуля нужно указывать явно.

Если имена одинаковые, а интерфейсы разные то программисту надо разложить код по разным "папкам".
Разумеется делает это программист вышестоящей системы.

Это все здорово, мне надо сейчас знать как помочь этому программисту вышестоящей системы, потому что от этого зависит внутреннее мироустройство вычислительной модели.
Итак я предлагаю складывать системы в ветви с названиями внешних модулей. Тогда вопрос с конфликтами имен будет решен автоматически. За это программисту придется расплачиваться явным указанием имени внешнего модуля. По принципу Внешний_модуль.Имя_системы, иначе просто нет возможности адресовать системы с одинаковыми именами.
Если особых замечаний нет, то я продолжу уже в таком ключе.

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

10

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Раз никто не пишет - будет первый вариант - внешние системы отныне имеют права на одинаковые имена, но их указание требует указание внешнего модуля.

Страница: 1

Вы здесь » Ремесло программиста » Валентина » Проверка корректности имени системы