Вот некоторые мысли по поводу объектов. Только объяснить это я никому не смог 8(

У каждого объекта есть каналы по которым он получает информацию из внешнего мира, и каналы через которые он воздействует на внешний мир. Кроме этого у него есть некоторое состояние - его цели и представление о том, как устроен внешний мир. С точки зрения объекта его методы это каналы через которые он получает информацию, а методы других объектов это каналы через которые он воздействует на внешний мир. При вызове метода объекта меняет свое состояние(цели или представление о внешнем мире) и выдает ответную реакцию (возвращает результат и вызывает методы других объектов).
Ограничение доступа проще всего сделать по следующему принципу: нельзя подействовать на то, чего нет. То есть если у объекта нет указателя на другой объект или его идентификатора, то подействовать на него он не сможет. Если к объекта есть указатель то подействовать на другой объект он может напрямую. А если у него есть идентификатор, то подействовать на него он может косвенно, вызвав метод того, кто дал ему этот идентификатор. Для других объектов данный идентификатор не имеет смысла, идентификатор это соглашение между двумя объектами о том, как им называть некоторый третий объект.
При создании объекта ему передаются указатели на объекты, с которыми он должен взаимодействовать для решения поставленной перед ним задачи. Для него это - его внешний мир. Кроме того у объекта есть внутренний мир, это объекты которые он создал для решения задачи, или моделирования внешнего мира. Доступ к этим объектам из вне возможен только через идентификатор. Вообще идентификатор также можно рассматривать как объект.

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

Очень даже неплохая картина мира.
Только здесь не видно частичного ограничения доступа. Допустим объекту #1 надо знать (или воздействовать) только на часть какого-то другого объекта #2, который (адрес которого) лежит внутри объекта #1. Пример: объект #2 содержит значение (или параметр состояния), которое предназначено только для чтения. Менять (воздействовать) на него может только объект #2. Так, что адрес объекта #2 всё равно необходим внутри объекта #1. Теперь, поскольку Ассемблер не имеет ключевого слова private, ничто не мешает объекту #1 делать что угодно с объектом #2.

Обойти это, наверное, невозможно...
Можно обращаться к объекту через список методов собранных в структуру - говоря по-простому - интерфейс (как в СОМ). Но, всё равно надо передавать this, опять же, имея this можно делать что угодно. Кроме того, мы будем иметь overhead, как в С++/СОМ.

Как ни крути, а Ассемблер просто не был спроектирован для ограничений.

Ассемблер - язык неограниченных возможностей!

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

Года три назад я скачал статьи с сайта Эльбруса, в которых описывалось много интересных решений. Сейчас там осталась только реклама. В тех статьях описывалась система защиты, основанная на типитизации памяти. С каждой 32х разрядной ячейкой памяти связывалось 2 битное поле тегов. В этом поле хранится информация о том, что находится в ячейке: обычные данные, код, указатель, дескриптор. Указатель занимает два слова(во втором слове вроде адрес дескриптора), а дескриптор четыре. Указатель и дескриптор должны быть выровнены на 2 и 4 слова соответственно. Если происходит запись в одно слово то указатель или дескриптор разрушаются, так как при доступе к ним процессор проверяет теги всех слов. Указатели, и дескрипторы программа может свободно копировать. При вызове функции для параметров выделяется память в стеке и создается дескриптор данной области, в эту область вызывающая функция помещает параметры. Вызываемая функция выделяет в стеке память для локальных переменных, и для этой области тоже создается дескриптор. Дескрипторы для локальных переменных и для параметров создаются процессором автоматически. При доступе к памяти проверяется не выходит ли адрес за границы указанные в дескрипторе, соответствуют ли права функции атрибутам дескриптора и т.д. Получить доступ к локальным переменным вызывающей функции, вызываемая функция может только если ей будет передан дескриптор или указатель на соответствующую область памяти. Фальсифицировать их не возможно. Для выделения памяти программе необходимо обратится к операционной системе, так как создание дескриптора для произвольной области памяти относится к привегелированным операциям. Стек данных отделен от стека с адресами возврата. В последнем вместе с адресом возврата сохранялся еще указатель на дескриптор локальных переменных функции. Еще были интересные механизмы для обработки исключений. Поиск обработчика осуществлялся аппаратно по спискам. То есть допустим поисходит деление на ноль, нарушение доступа или вызываемая функция сама сгенерировала программное исключение. В некоторый региср заносится код исключения а дальше процессор проходит по списку и ищет обработчик. Если данная функция не устанавливала обработчик, то происходит выход из функции и обработчик ищется в списке обработчиков вызвавшей функции. И так далее. Если обработчик не найден, то вызывается обработчик операционной системы. Данный механизм очень похож на то, что делается в С++. Еще там говорилось о поддержке защиты на уровне объектов только к сожалению тех статей у меня уже нет. Если у кого они вдруг остались киньте мне на мыло.

Вот очень интересная информация:
http://www.mstu.ru/studies/Others/War/IlbrusLanguage-docs.rar - лекции о процессоре Эльбрус.
Жаль что их так мало. В файле Т3з1Нов.doc как раз рассматриваются вопрос о внешних объектах.
http://www.mstu.ru/studies/Others/War/IlbrusLanguage-emul.rar - эмулятор процессора Эльбрус.

PS: Насчет того что поиск обработчика осуществляется по спискам я был не прав.
PPS: А что касается файловой системы, то ее стоит заменить на систему для хранения объектов 8)

Black_mirror
У каждого объекта есть каналы по которым он получает информацию из внешнего мира, и каналы через которые он воздействует на внешний мир.

Ага -- у меня это модель Оморфо ядра называется :))

При вызове метода объекта меняет свое состояние(цели или представление о внешнем мире) и выдает ответную реакцию (возвращает результат и вызывает методы других объектов).

Вот вот. Правильная идея!!!

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

Надеюсь в отдалённом времени я смогу поделится моделью Оморфо объектов. Зато очень приятно, что сама идея -- возникает не только в одной голове. Это вселяет уверенность :)

Black_mirror

файловая система может узнать права...

Пожалуйста, пояните, как с синхронизацией: "файловая система" проверяет все это в собственном треде системного процесса или в ядровой части юзерского треда?

'Можно ограничить доступ одного объекта к другим, поместив каждый объект в отдельное адресное пространство и заменив вызов методов отправкой сообщений.'
===
Мне кажется, в этом случае пострадает производительность кода, построенного на таких принципах... может быть я и ошибаюсь... но тогда чем такие объекты будут отличаться от ЯВУ?

Мне кажется, в этом случае пострадает производительность кода

Тут видимо имеется ввиду процессорная поддержка.

Valery
Я не предлагал конкретную реализацию этого механизма. Тут все будет зависеть от того, как построена операционная система. Если это система типа ДОСа и у всех программ права одинаковые, то проверять нужно только атрибуты файла. Если это система типа винды то узнать права можно после перехода в режим ядра посмотрев структуры связанные с процессом. А если это система типа QNX, то передавать права процесса можно либо с сообщением(приписываются к сообщению ядром при вызове функции ядра для его отправки), либо передавать только идентификатор процесса, а для определения прав запросившего тогда файловой системе потребуется обратится к другому объекту, например к диспетчеру процессов.

AsmGuru62
Edmond
Без процессорной поддержки падение производительности действительно будет. Сейчас вся защита объектов построена на програмном уровне. В теории объект может получить доступ к данным другого объекта только вызвав его метод. То есть все методы объекта должны быть public а данные private. А всякие protected были сделаны только из соображений эффективности. Но процессоры этого не проверяют, все это проверяется только на этапе компиляции.
От ЯВУ такая система не сильно отличается, только она является более гибкой. Здесь фиксируется только способ получения информации, но не способ ее отправки. На пути между отправителем и получателем может находится любое количество преобразователей информации. Отправителю даже не нужно знать куда он отправляет информацию. Внешний мир для него представлен каналами по которым он отправляет и получает информацию.
Внутри объекта может находится целая система объектов, для внешнего наблюдателя это абсолютно не важно. Для него важно только чтоб объект с которым он взаимодействует адекватно реагировал на его воздействия. Например если объект послал сообщение и ждет результат обработки он должен его получить. Программа есть система объектов построеная для решения какой-либо задачи. ОС - это система объектов созданная для распределения ресурсов. Наименьшей задачей для объекта является обработка сообщения. Вот для решения этой задачии и должны выделятся ресурсы, а не каким-то потокам, делающим неизвестно что. Правильное распределение ресурсов невозможно без представления о важности решаемых задач. Самый простой вариант приписать сообщениям и объектам приоритеты, только нужно хорошо разобраться как приоритет объекта и обрабатываемого им сообщения будет влиять на приоритеты отправляемых сообщений.

PS: Очень рекомендую прочитать о процессоре Эльбрус(ссылки в предыдущем сообщении). Наверняка возникнет много интересных идей.

AsmGuru62
поместив каждый объект в отдельное адресное пространство

А в MSVC есть такая штука как namespace или пространство имен. Есть ли аналог в ассемблере? и возможен ли он?

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

DaemoniacaL

В ассемблере есть модули.. В принципе с ними можно всё, что и с namespace
(скоро макро будут)

Edmond
в namespace не обязательно должны быть разные модули, а также он может состоять из нескольких модулей.

Только я не об этом. Идею можно попытаться использовать для описания объектов в асм. Если уж PRIVATE не удается сделать.