Я тут http://www.rsdn.ru/Forum/Message.aspx?mid=1862408&only=1

Автор: WoldemaR
Дата: 22.04.06

прикинул что и как да почём, кому интересно — заходите.

Кстати, может какие ообд так уже работают? Никто не в курсе.

Здравствуйте, Ligen, Вы писали:

L>Разработчики студии, видимо, справедливо решили что такая возможность программисту не нужна.
L>А в достаточно популярном донельзя гуевом MS Word достаточно: ALT-F11, двойной клик на This Document и выполнить (F5) следующее:
В студии тоже можно макросы писать... через все тотже Alt+F11... Болие того студия умеет записывать и воспроизводить действия пользователя. Ctrl+Shift+R, записываем действия, Ctrl+Shift+R далие при помощи Ctrl+Shift+P воспроизводим действия нужное колличество раз.
Кстати вот такой макрос

    Sub TemporaryMacro()
        DTE.ActiveDocument.Selection.WordLeft(True)
        Dim s = DTE.ActiveDocument.Selection.Text
        DTE.ActiveDocument.Selection.Text = ""
        For i = 1 To Integer.Parse(s)
            DTE.ActiveDocument.Selection.Paste()
        Next
    End Sub

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

А вот такой макрос

    Sub TemporaryMacroN()
        DTE.ActiveDocument.Selection.WordLeft(True)
        Dim s As String = DTE.ActiveDocument.Selection.Text
        DTE.ActiveDocument.Selection.Text = ""
        Dim i As Integer
        For i = 1 To Integer.Parse(s)
            RecordingModule.TemporaryMacro()
        Next
    End Sub

позволяет выполнять записанные действия N раз.

MS>Кто вам мешает, чтобы за всеми документами был базовый класс файл с теми же самыми методами, свойствами и т.п., что и сейчас? Кто вам сказал забудем про файлы вообще? Вы как-то не очень понимаете, что просто сейчас есть только 1 класс — файл. Ну есть еще какие-то доступные разные методы через что-то. Но мало, вяло и несерьезно. А надо чтобы было хорошо, много и прямо.

Все я прекрасно понимаю. Сейчас есть суперкласс "файл", от которого унаследованы подклассы типа "MS Word Document", типа "бинарь" (имеет закладку Version в шелле), и прочие подобные.

Вы предлагаете сделать все это более развитым. Пожалуйста. Но "файл" как базовая сущность — дата-время, флажки, имя и содержимое, которое в самом классе "файл" не интерпретируется — он останется. Низкий уровень файловых систем трогать не нужно.

Все эти классы могут быть сделаны на уровне интерпретации содержимого файла и понятия "формат файла". Так это успешно и делается уже многие годы.

WinFS даже скорее не об этом, а скорее о расширении понятия "директория". Т.е. там будут "директории" не по имени файла, а по какому-то кастом-атрибуту — например, "второе имя" файла, или мало ли что там еще.

Такие вещи можно сделать, либо тронув низ файловой системы (и, насколько я знаю, в Ntfs таки подымут в полный рост экспериментальную подсистему NtOfs, которая именно это и делает), либо создав метаданные, скажем, в MDB файле (как Thumbs.db) сбоку от файловой системы. Там будут храниться значения кастом-атрибутов для всех файлов на томе, и индексы по ним.

>на что-то другое. И Windows нужен был не тем, кто сидел в ДОС, а тем, для кого это было неприемлимо.

Я ж помню, как Windows захватывал рынок. Через 3rd party developers в основном, а не через юзеров.

Windows решал для девелопера 2 проблемы а) использование всей памяти машины и б) совместимость сразу с любыми принтерами. Под Windows было удобнее девелопить, чем под ДОС, потому под нее сразу появилось много приложений, некоторые из них Windows-only.

А юзеры туда пошли только тогда, когда уже все эти приложения там были. Многие юзеры у нас в России так и сидели в ДОС до появления Windows 95 (в которой основной key point с точки зрения рынка был — сеть).

Именно из-за приложений (и еще многозадачности — не надо выходить из старой программы, чтобы открыть новую, причем многозадачность была еще и для ДОС задач) юзера туда и пошли, а не из-за UI. Под ДОСом был тот же ТурбоВижн — прекрасный UI, для неграфических задач типа финансов ничем не хуже Windows. Собственно, турбовижновскую 1С-Бухгалтерию я видел у людей еще в начале 2000ных годов.

Видел и такую картину — в виндах стоят Ворд, Эксел, и на DOS VM бегает сразу 2 рабочих места "Паруса".

Здравствуйте, shuklin, Вы писали:

S>У меня эта проблема решена лишь частично. Выгрузить assembly саму по себе невозможно. Тут даже не моя причина а .NET так работает.

Можно. Грузишь её в отдельный домен, потом домен прибиваешь и сборка выгружается.

Здравствуйте, shuklin, Вы писали:
S>Наверное самая изветная тупиковая попытка — ODMG ИМХО она провалилась из за "проблем" с идентичностью объектов.
Неа. Она провалилась из-за того, что в
— в OQL встроили слищком могучий type inference. Ни один ЯП общего назначения на тот момент не был способен с этим справиться; в итоге, значительная часть OQL — запросов просто не позволяла представить свои результаты в языке "клиента".
— в OQL отказались от описания семантики методов, возложив эту задачу на внешний язык.
Таким образом, вместо того, чтобы стереть грань между DB и OO, эти орлы возвели непреодолимую стену. Даже просто реализовать этот мусор оказалось невозможным; построить приемлемо эффективную реализацию — тем более.
Мне неизвестны какие-либо проблемы с identity, присущие ODMG OQL. Возможно, я просто не смотрел в нужную сторону. Ты не мог бы рассказать, какие именно проблемы сулит ODMG-подход к identity?

Заодно поясни, зачем ты отказался от основы ООП в своей СУБД — ведь identity это базовая концепция?
Ну вот я могу себе представить алгоритм, который полагается на то, что из identity(a) == identity(b) следует, что a и b — это один и тот же объект. И модифицируя состояние объекта через ссылку а, мы гарантированно получим тот же результат, что и через ссылку b.
Опять же я могу представить себе алгоритм, зависящий от того, что из identity(a) != identity(b) однозначно следует различность этих двух объектов.
Нарушение этих предположений может привести к достаточно тяжким проблемам с семантикой.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Более фундаментальная задача: реализация модели бесконечной персистентной памяти. Нужно реализовать среду времени исполнения, которая работает в рамках этой модели. ОС и всякие БД пусть работают поверх этой среды времени исполнения.
Это как раз не штука. Интригу в эту "более-менее фундаментальную задачу" можно добавить, к примеру, так: реализовать эффективный механизм выполнения запросов в этой модели.
Что понимается под запросом? Поиск множества объектов, удовлетворяющих заданному предикату.
Что понимается под "эффективным"? Тут немного сложнее. Во-первых, есть полное количество экземпляров в модели — пусть это будет N.
Во-вторых, есть количество объектов, которые фактически удовлетворяют заданному предикату. Пусть это будет R<p>.
Предположим, что сам предикат p позволяет вычислить его на произвольном экземпляре с затратами, не зависящими ни от N, ни от R<p>.
В случае, если модель позволяет перечислить все объекты за время порядка O(N), мы можем выполнить запрос с такой же асимптотикой.
Задача состоит в том, чтобы улучшить эту асимптотику; в идеале — до O(R<p>) на достаточно широком классе предикатов.

Здравствуйте, AVC, Вы писали:

MSS>>Вывод: понятие файла и приложения — прошло проверку временем, и, скорее всего, навсегда. Над ним могут быть разные абстракции, но оно само — навсегда.
AVC>Кроме того, понятие файла фундаментально для UNIX. ("Все есть файл.")

А кроме того, нет ничего проще, чем выделить кусок места в хранилище и дать ему имя...

AVC>Но когда-нибудь и UNIX устареет...

Угу. Вместе с компьютерами.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Windows решал для девелопера 2 проблемы а) использование всей памяти машины и б) совместимость сразу с любыми принтерами. Под Windows было удобнее девелопить, чем под ДОС, потому под нее сразу появилось много приложений, некоторые из них Windows-only.
Третья немаловажная причина в том, что Microsoft предлагал практически готовое рабочее место Windows+Office. Что не сильно потом нравилось антимонопольным властям.

GZ>Третья немаловажная причина в том, что Microsoft предлагал практически готовое рабочее место Windows+Office. Что не сильно потом нравилось антимонопольным властям.

Имели право. Они же не продавали их в одной коробке.

Антимонопольным властям не нравился стиль MSных OEM контрактов, когда оплата была не от количества установленных виндов, а... от количества проданных OEMщиком машин. Т.е. на уровне бизнеса просто блокировался интерес к преинсталляции любой ОС, кроме виндов, ибо за винду платить все равно.

Итог — в 93-94 годы все брэнды, кроме IBM, были с преинсталлированными виндами, и только виндами — другая ОС в преинсталле не встречалась. Только у IBM не было преинсталлированных виндов, а была либо ДОС, либо полуось.

Судья Споркин открыл процесс. По ходу процесса MS договорился с министерством торговли (или как оно там), что MS это дело прекращает. Министерство отозвало иск из суда, а Споркин сказал — "вы не сделаете из меня дурачка, который подписывает все, что ему суют" — и стал продолжать дело. Итог — дисквалификация Споркина.

Потом был еще Джексон, но это уж потом.

Здравствуйте, Maxim S. Shatskih, Вы писали:

GZ>>Третья немаловажная причина в том, что Microsoft предлагал практически готовое рабочее место Windows+Office. Что не сильно потом нравилось антимонопольным властям.
MSS>Имели право. Они же не продавали их в одной коробке.
Просто когда стало ясно, что и офис и Windows стали монополистами, шли упорные слухи что решением суда и антимонопольного комитета будет разделение корпорации на две части: которая занимается OS, и которая занимается офисом. Но Microsoft постоянно с кем то договаривается.

Здравствуйте, Дарней, Вы писали:

Наверное, если у народа будет желание, лучше обсудить "войну редакторов" в специальном топике.
Не хочется мешать основной теме.

AVC>>А вообще "типичная задача" — понятие относительное.

Д>вполне даже абсолютное... хочешь, опрос проведем?
Д>я не думаю, что найдется хотя бы 0.1% людей, для которых возможность вставки заданного количества одинаковых строк в код является определяющей при выборе IDE

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

Д>а может, надо просто проектировать языки таким образом, чтобы хотя бы простые вещи не требовали средств автоматизации работы?

Так-так. Шутить изволите.
Вот, небось, сидишь сейчас в навороченной среде.
Редактор, конечно, с синтаксической подсветкой.
И хочешь поговорить о Простых Вещах.
OK.
Вот Простой Вопрос.
Как ты думаешь, что проще автоматизировать: проверку на завершение ввода ключевого слова или синтаксическую подсветку?
Что же касается собственно дизайна ЯП, то хорошо спроектирован тот язык, что не требует многочасовых сидений в отладчике.

AVC>>А vi (или vim) практически везде одинаков (и везде доступен).

Д>Только пользоваться этим допотопным чудом мало кто хочет.

Так я никого и не заставляю...

AVC wrote:
> Не в этой отдельной фиче дело, а в том, что я получаю ее бесплатно.
> Так уж устроены документы в Обероне, что в них можно вставлять
> произвольные объекты.
Ну в Виндовом OLE точно так же можно делать. И что?

Здравствуйте, Cyberax, Вы писали:

>> Не в этой отдельной фиче дело, а в том, что я получаю ее бесплатно.
>> Так уж устроены документы в Обероне, что в них можно вставлять
>> произвольные объекты.
C>Ну в Виндовом OLE точно так же можно делать. И что?

Разница в простоте.
При том, что Оберон возник раньше.
При несоизмеримости вложенных человеко-лет.

Здравствуйте, AVC, Вы писали:

AVC>Наверное, если у народа будет желание, лучше обсудить "войну редакторов" в специальном топике.
AVC>Не хочется мешать основной теме.

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

AVC>Хм... и после такого голосования мои типичные задачи изменятся?

а с чего ты взял, что меня интересуют твои типичные задачи? Меня интересуют типичные задачи типичного программиста... тем более, что уж возможности текстового редактора всем нужны примерно одни и те же.

AVC>Разве дело только в том, чтобы вставить 1000 одинаковых строк?

ну хорошо. Любая задача, которая требует повторить операцию строго n раз. Я с трудом могу представить, кому и при каких обстоятельствах это может понадобиться А это, тем не менее, преподносится как одна из крутейших фич vim.

AVC>Так-так. Шутить изволите.
AVC>Вот, небось, сидишь сейчас в навороченной среде.
AVC>Редактор, конечно, с синтаксической подсветкой.
AVC>И хочешь поговорить о Простых Вещах.

да, сижу. Только она делает не постые вещи, а вполне даже сложные. Авто-комплит по именам классов и методов, переименование, resolve namespae — это наверно самое полезные фичи... но помощь писать ключевые слова без выворачивания пальцев в число таких фич точно не входит

AVC>OK.
AVC>Вот Простой Вопрос.
AVC>Как ты думаешь, что проще автоматизировать: проверку на завершение ввода ключевого слова или синтаксическую подсветку?

зависит от языка, но обычно пункт 1 проще

AVC>Что же касается собственно дизайна ЯП, то хорошо спроектирован тот язык, что не требует многочасовых сидений в отладчике.

перпендикулярно

Здравствуйте, Sinclair, Вы писали:

S>Ты не мог бы рассказать, какие именно проблемы сулит ODMG-подход к identity?

Очень трудно создать VIEW в такой ОБД. Допустим у нас есть объект город и справочник города. И есть объект компания у которой указатель на город. Далее нам нужен производный объект Компания у которой вместо указателя на город находится его имя — аналогично РБД шному JOIN. Итак сделали такой объект. Теперь вопрос, а какой ИД у этого производного объекта? В РБД — тот же что и у исходной компании. А в ОБД какой? Новый? Новый нельзя. И без VIEW тоже нельзя — надо ведь сохранять совместимость с legacy.

S>Заодно поясни, зачем ты отказался от основы ООП в своей СУБД — ведь identity это базовая концепция?

В первую очередь из за игр с семантическими сетями. Там с ODMG трактовкой OID делать нечего. Ну например, нужно мне добавить в объект на рантайм новую именованную связь, а связи дать дополнительные аттрибуты. Связь логично окрасить тем же ОИД. Тогда из текущено объекта связанный объект должен быть разадресован не по ид этого объекта а по ид связи с ним. В итоге смысл уникального ОИД полностью теряется на уровне пользователя. Ну много причин. А главная, моя концепция включает ODMG как частный случай. Ведь можно не значит необходимо. Если в какомто случае синонимию/омонимию OID не нужна — то можно ей не пользоваться, назначая во всех контекстах одинаковым объектам одинаковые OID.

Я в своей ОБД широко использую этот механизм для адресации аттрибутов объектов. Есть список аттрибутов. Каждый аттрибут имеет свой описатель — тоже объект с некоторым ИД. Однако любой другой объект по этому ИД получает не описатель, а значение этого аттрибута. Так например Аттрибут имя имеет аттрибут с собственным ИД и со значением "Имя". Подробнее это описано здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx

Здравствуйте, shuklin, Вы писали:
S>Очень трудно создать VIEW в такой ОБД. Допустим у нас есть объект город и справочник города. И есть объект компания у которой указатель на город. Далее нам нужен производный объект Компания у которой вместо указателя на город находится его имя — аналогично РБД шному JOIN. Итак сделали такой объект. Теперь вопрос, а какой ИД у этого производного объекта?
Никакого, потому что это не объект. Я же говорю — проблема OQL как раз в том, что легким манием руки порождаются новые типы. К счастью, конструировать объектные типы нельзя, потому и вопрос об OID лишен смысла. После операторов проекции или join получается неидентифицируемый кортеж.
S>В РБД — тот же что и у исходной компании.
И в РБД у него никакого PK нету. Ровно по той же причине.
S>А в ОБД какой? Новый? Новый нельзя. И без VIEW тоже нельзя — надо ведь сохранять совместимость с legacy.

S>В первую очередь из за игр с семантическими сетями. Там с ODMG трактовкой OID делать нечего. Ну например, нужно мне добавить в объект на рантайм новую именованную связь, а связи дать дополнительные аттрибуты. Связь логично окрасить тем же ОИД. Тогда из текущено объекта связанный объект должен быть разадресован не по ид этого объекта а по ид связи с ним. В итоге смысл уникального ОИД полностью теряется на уровне пользователя. Ну много причин. А главная, моя концепция включает ODMG как частный случай. Ведь можно не значит необходимо. Если в какомто случае синонимию/омонимию OID не нужна — то можно ей не пользоваться, назначая во всех контекстах одинаковым объектам одинаковые OID.

S>Я в своей ОБД широко использую этот механизм для адресации аттрибутов объектов. Есть список аттрибутов. Каждый аттрибут имеет свой описатель — тоже объект с некоторым ИД. Однако любой другой объект по этому ИД получает не описатель, а значение этого аттрибута. Так например Аттрибут имя имеет аттрибут с собственным ИД и со значением "Имя". Подробнее это описано здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx
Надо бы почитать. Пока что звучит как ересь

Здравствуйте, Sinclair, Вы писали:

S>Никакого, потому что это не объект. ... После операторов проекции или join получается неидентифицируемый кортеж.

Вспомним тот же пример — компания и город. Пусть у компании было текстовое поле — "город". Ввели систему в эксплуатацию. Она проработала с год. Появились реализации тулзов третьей стороны. Теперь надо текстовое поле "город" в объекте компании заменить на указатель. Без нарушения совместимости с уже существующим кодом. В РБД для этого можно использовать VIEW. В данном простом примере можно выкрутится за счет проперти. Но а если у нас структура БД поплыла? Надо делать вьюшки, причем такие, чтоб они выглядели для старых клиентов полноценными экземплярами объектов старого формата.


S>Надо бы почитать. Пока что звучит как ересь

Вот благодаря этой ереси эта проблема решаема и в ОБД.

Здравствуйте, shuklin, Вы писали:
S>Вспомним тот же пример — компания и город. Пусть у компании было текстовое поле — "город". Ввели систему в эксплуатацию. Она проработала с год. Появились реализации тулзов третьей стороны. Теперь надо текстовое поле "город" в объекте компании заменить на указатель. Без нарушения совместимости с уже существующим кодом.
Это невозможно. Как ты себе представляешь этот гипотетический существующий код? С учетом того, что теперь нельзя делать

update company set city = 'Новосибирск' where companyId = @companyId

Тебе придется искать такие вызовы по коду, вводить отдельный справочник городов, UI к нему и прочее и прочее.
Пойми, что структура данных сама по себе никогда не меняется. Меняются требования. И возможность адаптироваться к изменившимся требованиям одной лишь структурой БД — это миф.
Впрочем, есть одна ситуация, когда то, о чем ты говоришь, теоретически возможно. Это оптимизация по результатам эксплуатации. Всякая денормализация и прочее. Теоретически, в таких случаях (если клиенское приложение написано исключительно через хранимые процедуры и view) можно воспользоваться этой замечательной инкапсуляцией.
Но беда в том, что на практике потребность оттюнить перформанс при помощи изменений структуры (а не подстройкой индексов) возникает намного реже, чем изменения в требованиях.

S>Вот благодаря этой ереси эта проблема решаема и в ОБД.
То, что ты сделал, нельзя называть ОБД. Потому что основных черт ОБД у этого нету.
Ну вот придумал ты способ называть результат join объектом. Ок, вот мы заджойнили кошечку со шкафом. А методы у этого чуда от кого будут?

Здравствуйте, Sinclair, Вы писали:

S>Это невозможно. Как ты себе представляешь этот гипотетический существующий код?

Я это уже сделал. Объекты FieldDescriptor притворяются объектами AttributeDesctiptor именно на основе одной из возможностей моей СУБЗ. На самом деле FieldDescriptor не идеальное решение и для Cerebrum. Там используется полиморфизм поведения ядра. Тоже самое можно сделать на основе полиморфизма структуры. Вот только сущесвующая реализация экспорта/импорта полиморфизм структуры еще не поддерживает. Поэтому FieldDescriptor работают по старинке.

S>Ну вот придумал ты способ называть результат join объектом. Ок, вот мы заджойнили кошечку со шкафом. А методы у этого чуда от кого будут?

Паттерн Wrapper|Bridge