Отсутствие высокоуровневых фич вроде структурной обработки исключений, прозрачного разыменования указателей и Delphi-style классов отчасти оправдано. Мне нравится сравнение DOSBox с учебной виртуальной машиной Mix Дональда Кнута. Но Mix — учебная, неживая, а DOSBox хранит на себе печать эпохи. Можно поковырять его AVPUtil'ом, не хуже, чем Mix.
Представь, что ты поставил WiFi и хочешь, чтобы доступ в Интернет покупался за деньги. Если брать реальные деньги, с тебя будут трясти лицензию. А BitCoin — когда надо — деньги, когда надо — не деньги. Нет денег — нет незаконного предпринимательства — нет претензий.
Представь, что ты в каком–то гипотетическом файлообменном протоколе хочешь поощрять раздающих и релизёров деньгами. Опять приходим к тому же: нельзя платить настоящими деньгами.
Представь, что у тебя современный компьютер, много места на HDD и хороший канал в Интернет, и ты бы не против получать денюжку за свои мощности, но открывать и вести ИП очень дорого, нерентабельно, и опять же лицензии, счёт в банке, отчётность в налоговую. Да и заказчиков можно не найти: компьютер может выключаться, Интернет по району может не работать. И тут появляется сервис–посредник, который тестирует доступность узлов, обеспечивает избыточность сети, распределяет доходы. Заказчикам — нестабильное, но дешёвое облако. Исполнителям — возможность получить хоть какие–то деньги просто за то, что компьютер работает. Главное, чтобы в одном месте деньги были деньгами, а в другом месте — математикой и криптографией.
Столько нереализованных идей не могли осуществляться из–за того, что не было программно доступных денег.
То, что сейчас BitCoin можно зарабатывать только майнингом — это незрелость. BitCoin — это деньги для Интернета, и в подобных проектах и проявится их истинное назначение.
Как можно расширить базовый класс средствами только COM?
У нас есть возможность получить из чужой библиотеки готовый экземпляр кокласса или же фабрику, которая сделает экземпляр. Переделать уже созданный экземпляр в его как бы потомка без агрегации не представляется возможным.
Плохо, что эта вещь не является drop-in replacement. Когда вышел SOM 2.0, это не сломало приложения, использующие SOM 1.0, хотя у первого и второго были существенные отличия. NOM не продолжает эту традицию. NOM плохо документирован и существует в большей степени не сам по себе, а ради того, чтобы был сделан Voyager, кроссплатформенный аналог WPS. Из того, что я читал про WPS, помню, что SOM там используется по–особенному, не полностью, и, если, например, использовать множественное наследование, WPS падает. В связи с чем напрашивается вопрос, а не будет ли NOM таким же недо–SOM, который применяется в WPS?
Да, но это не то же самое. Нельзя взять какой–нибудь базовый кокласс, как–нибудь без проблем агрегировать его, добавить своих функций и использовать как аргумент метода, ожидающий предка (а не интерфейс предка). На одних интерфейсах всего не сделаешь, часто нужно, чтобы полученный объект имел не только фиксированный интерфейс, но и особенность реализации внутри себя. Ну, скажем, нельзя реализовать какой–нибудь не предназначенный для этого интерфейс Office и передать этот фальшивый объект настоящему объекту Office как аргумент. Или, если написать COM–версию ASIO, то рано или поздно дело дойдёт до select(), и потребуются OS–специфичная информация.
При наследовании предок управляет тем, какие интерфейсы будут у потомка, и набор этих интерфейсов может измениться без участия потомка. При агрегации только контейнер единолично решает, какой набор интерфейсов он поддерживает, реализуя сам или делегируя одному из агрегированных объектов. Даже, если переписать эту логику на обратную: все интерфейсы, которые мы не знаем, направлять на делегацию внутреннему объекту, среди этих неизвестных интерфейсов может оказаться следующая версия интерфейса объекта, и в этом случае нужно что–то сделать, чтобы старые методы этого неизвестного интерфейса обрабатывались контейнером. Это можно сделать при помощи кооперации со стороны внутреннего объекта. Наверное, ничего неразрешимого, но дело в том, что это не является продуманным вариантом использования COM, и, если работать в этом направлении, то будет написан новый код, который частью COM не будет, и, учитывая все уровни косвенности, результат будет хуже, чем если с самого начала делать объектную систему, поддерживающую весь набор трансформаций.
NAT тоже ограничен количеством портов (65535) на IP. 10-15 лет? Вряд ли.
Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.
Мне как выход нравится автоматическая настройка IPv6 поверх IPv4. Например, вот есть сейчас в инсталляторах Яндекс.Бары не очень нужные, а почему бы не делать таким же образом конфигурацию IPv6?
Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
И, по–хорошему, те же действия роутер должен делать для Teredo и 6to4 (если полученный IPv4 не серый). Предположительно, доступ к другим Teredo узлам будет быстрее через Teredo, чем через нативный IPv6, и аналогично с 6to4.
Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.
Роутер должен через PPPoE, RA или DHCPv6 получить от провайдера настройки для себя, сделать на их основе настройки для LAN и начать анонсить их в LAN по DHCPv6 и RA.
Если такое будет, то рано или поздно мы упадём в пропасть. К примеру, человек досрочно выписался из психбольницы и имеет возможность занять место в госдуме. Он пришёл на работу, написал закон и произвёл переворот, не выходя из Кремля
Отсутствие высокоуровневых фич вроде структурной обработки исключений, прозрачного разыменования указателей и Delphi-style классов отчасти оправдано. Мне нравится сравнение DOSBox с учебной виртуальной машиной Mix Дональда Кнута. Но Mix — учебная, неживая, а DOSBox хранит на себе печать эпохи. Можно поковырять его AVPUtil'ом, не хуже, чем Mix.
Представь, что ты в каком–то гипотетическом файлообменном протоколе хочешь поощрять раздающих и релизёров деньгами. Опять приходим к тому же: нельзя платить настоящими деньгами.
Представь, что у тебя современный компьютер, много места на HDD и хороший канал в Интернет, и ты бы не против получать денюжку за свои мощности, но открывать и вести ИП очень дорого, нерентабельно, и опять же лицензии, счёт в банке, отчётность в налоговую. Да и заказчиков можно не найти: компьютер может выключаться, Интернет по району может не работать. И тут появляется сервис–посредник, который тестирует доступность узлов, обеспечивает избыточность сети, распределяет доходы. Заказчикам — нестабильное, но дешёвое облако. Исполнителям — возможность получить хоть какие–то деньги просто за то, что компьютер работает. Главное, чтобы в одном месте деньги были деньгами, а в другом месте — математикой и криптографией.
Столько нереализованных идей не могли осуществляться из–за того, что не было программно доступных денег.
То, что сейчас BitCoin можно зарабатывать только майнингом — это незрелость. BitCoin — это деньги для Интернета, и в подобных проектах и проявится их истинное назначение.
У нас есть возможность получить из чужой библиотеки готовый экземпляр кокласса или же фабрику, которая сделает экземпляр. Переделать уже созданный экземпляр в его как бы потомка без агрегации не представляется возможным.
Сильно смущает обязательная сборка мусора в NOM
При наследовании предок управляет тем, какие интерфейсы будут у потомка, и набор этих интерфейсов может измениться без участия потомка. При агрегации только контейнер единолично решает, какой набор интерфейсов он поддерживает, реализуя сам или делегируя одному из агрегированных объектов. Даже, если переписать эту логику на обратную: все интерфейсы, которые мы не знаем, направлять на делегацию внутреннему объекту, среди этих неизвестных интерфейсов может оказаться следующая версия интерфейса объекта, и в этом случае нужно что–то сделать, чтобы старые методы этого неизвестного интерфейса обрабатывались контейнером. Это можно сделать при помощи кооперации со стороны внутреннего объекта. Наверное, ничего неразрешимого, но дело в том, что это не является продуманным вариантом использования COM, и, если работать в этом направлении, то будет написан новый код, который частью COM не будет, и, учитывая все уровни косвенности, результат будет хуже, чем если с самого начала делать объектную систему, поддерживающую весь набор трансформаций.
Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.
Мне как выход нравится автоматическая настройка IPv6 поверх IPv4. Например, вот есть сейчас в инсталляторах Яндекс.Бары не очень нужные, а почему бы не делать таким же образом конфигурацию IPv6?
Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.