Пространство имён типов.

Иерархическое. ASCII. Компоненты пишутся через точку (двоеточие? слеш?) слева направо от общего к частному. Все типы, кроме тех, что начинаются с .local - глобальны и одинаковы везде на свете. То есть .user.microsoft.word.1.0 обозначает на всех Фантомах мира один и тот же класс, представление которого и код бит в бит совпадают везде.

Имя типу даёт программист, создающий приложение, библиотеку или драйвер. Класс, короче. Чтобы два разных программиста никогда не назвали своё творение одинаково, существуют несколько методов генерации уникальных имён и, соответственно, несколько ветвей имён - .user, .geo, .map. Названия не идеальны, но это не принципиально. :-)

Class

Он и есть. Это тип такой. Возможно, его нужно запихать в ветвь language. Возможно, ветви language и system нужно слить вместе. Они обе предопределены и реализованы подземно. А может и не надо - короче писать будет, и всего-то проблем. :-)

Language:

Language.int.8, language.int.16, language.int.32, language.int.64, Language.uint.8, language.uint.16, language.uint.32, Language.uint.64, language.string, language.float32, Language.float.64, language.float.80, language.bool, language.char

Language.Code.Executable.Interpreted

возможно: Language.List, Language.set - NB! - это концептуальный, а не технический вопрос.

возможно: Language.code.executable.intel.32, Language.code.executable.alpha.64, etc. Это уже, скорее, техничский вопрос.

возможно: language.code.source, но, скорее, нет - тянет за собой в список обязательных целую тучу классов, будет камнем на шее встроенных (и вообще недевелоперских) систем, да и вообще-то, языков может быть много. :-)

System:

System.Const, Sysem.Kernel, System.Thread, etc.

System.driver - абстрактный класс

Exception:

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

Exception.Out_of_space

Exception.Connection_broken

Exception.Reboot_happened

Local:

Любой тип внутри этой ветви порождён конкретно в данной инкарнации ОС и гарантированно отличается от всех других типов на свете. Это для скриптинга. Если вы сели и написали за пять минут скрипт о трёх строках (он же тоже класс, не так ли), то тип ему можно дать из этой ветви, чтобы не морочить себе голову выдумыванием глобально уникального имени.

User:

user.microsoft.word, user.comptek.yandex, etc

Имя второго уровня должно быть получено в каком-то central authority. Не знаю, в каком.

Geo:

эта ветвь позволяет не получая собственного имени в ветви user создавать классы для Фантома, то есть программировать под него. Вторым уровнем в нём идёт место и время создания класса - координаты (широта, долгота) и время с точностью до секунды. (Тут нужно определить степень точности, достаточную для гарантии от дубликатов)

Map:

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

map.russia.moscow.baryshikha-40-1-110.dz.zip_container

Вероятно, в программах нужно будет писать начиная с точки те типы, которые указаны полным именем. К остальным же компилятор автоматически должен привинчивать site prefix - у меня, к примеру, вышеуказанный map.russia.moscow.baryshikha-40-1-110.dz. Тогда тип .class будет считаться встроенным, а class преобразуется в map.russia.moscow.baryshikha-40-1-110.dz.class

Или вот хороший пример:

class exception : .exception { ... }
class exception.dz_needs_more_beer : exception { ... }

отметим, что базовый класс в первой строке начинается с точки.

Строки

unicode, видимо, 16-битный

Версии и совместимость

Определённая проблема. :-( Вообще говоря, закрытость данных объектов для внешнего мира облегчает вопрос обновления версий, конечно, но это всё равно сложное место.

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

Положим, имя типа состоит из двух компонент - сбственно именующей и номера версии. Программист выпускает user.microsoft.word.1, потом user.microsoft.word.2, потом user.microsoft.word.2.1 - и так далее.

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

Далее, сам класс. Класс - тоже объект, и при потере последней ссылки на него он исчезнет. Это можно использовать. Если мы хотим изничтожить старую версию, то достаточно удалить её из системного каталога классов (по которому, кстати, и производится поиск по имени типа). Пока объекты этого класса живут - будет жить и он. Умрут - захватят с собой и папу.

В принципе, чтобы форсировать умирание нужно скопировать все объекты и удалить оригиналы. При копировании отработает copy constructor. Поскольку по умолчанию имя класса указывается без номера версии - он будет самого свежего класса. Тут, конечно, гарантии нет - только если старая и новая версия достаточно сильно совместимы и программист, создававший copy constructor всё правильно написал конструктор сработает.

Какие здесь видны подводные камни.

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

Если честно - есть сильное желание вообще ограничить доступ к пузу объекта насмерть - чтобы только личный метод класса, и только в отношении к объекту, в контексте которого он вызван имел право на "доступ к телу". А protected в отношении данных объекта - тоже запретить.

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

Такое вытворял IBM в OS/2 SOM - и даже с доступом порождённого класса к внутреннему представлению породившего. Что-то типа высшего пилотажа. Меня это вытворять, если честно, не тянет.

Меня тянет запретить protected, жёстко привязать порождённый класс к версии базового и если кто-то сделал extended word document 1.0, то пусть или делает 2.0, или 2.0 останется без экстеншна.

Безымянные типы.

В принципе ничто не мешает существованию полностью анонимных типов. Собственно, достаточно при установке не регистрировать тип в системе, и он не будет иметь имени. Создать объект такого типа, тем не менее, возможно, если иметь указатель на объект типа class для этого типа. На данный момент запрещать это поведение я не вижу причин. И способов. :-) Как реализовать это в языке - отдельный открытый вопрос.

О массивах и контейнерах

У меня есть сильное желание изничтожить массивы. Строка от этого не пострадает - мы не в Си, чай. А вместо массивов ввести множества, списки, деревья - короче, джентльменский набор контейнеров. Плюс байтовый контейнер. Старьё в нём хранить. :-)

Отчего нелюбовь к массивам? Ну, во-первых, всё хорошо, пока это массив int-ов - его можно реализовать эффективно внутренними силами. Массив объектов невстроенного типа - это всё равно массив указателей или класс.

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

Нет, то есть индексируемые среди них тоже должны быть, конечно. Не обязательно только int-ом, привет, awk и perl, а чем душенька захочет.

Только это неязыковое средство. Впрочем, что в Фантоме - языковое средство... оператор while, разве.

Проблема: это всё очень здорово, если писать ms word или html-редактор. А вот MPEG-декодер или обсчёт чего-нибудь матричного, или игру quake хорошо писать, имея эффективно доступные массивы целых и флоатов. Вопрос - озаботиться этим, или через пару лет на частоте процессоров в 2 ГГц и при наличии супер-пупер тридэ акселератора проблема перестанет быть актуальна?

Каталог

Напрашивается стандартный тип по имени directory. Да-да, то самое. :-) Куда шелл будет объекты пользователя складывать. С их именами - этикетками такими...

Формально - множество пар <имя, указатель на объект>. Или <имя, указатель на дескриптор, указатель на объект> - это чтобы можно было привинчивать пространные описания и/или иконки. :-)

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

Представляется, что стандартизовать такой тип было бы очень кстати. Будет хуже, если каждый шелл начнёт выдумывать своё хранилище.