Про 1С++ООП, на ночь глядя бесстыжими вочами

[Djelf]

В результате отпилили не критичные 10см в сборке и успокоили

И бы не пилил, я бы сдул, и всё влезло бы. Надули просто, перестарались )

Да не было такого, я сам пересчитывал. И сам измерял!
Парадокс какой то был: если бы сам не видел и не считал, то и не поверил бы в такое никогда, но я это это видел своими глазами, и это было подтверждено стронней которой и моей бывшей женой. Полтелгейст какой то был...

Нет, я не был "под мухой".
Сборщик тоже не был  "под мухой".
Жена тоже...
Неразгаданая загадка...

Ну раз ты тут Эйнштена приводишь, то возможно всякое, вплоть до искривления пространства/времени, в отдельной взятой кухне...

[Forum123]

Ну раз ты тут Эйнштена приводишь, то возможно всякое, вплоть до искревления пространства/времени, в отдельной взятой комнате...

В панельных хрущёвках расхождение стен в комнатах запросто 10 см. и более бывает.

[Пиит]

... Ну раз ты тут Эйнштена приводишь, то возможно всякое, вплоть до искревления пространства/времени, в отдельной взятой комнате...

Не, домой я его не приводил, он сам пришёл, с Менделеевым.
Зная Ваши химические таланты, коллега, тут по шкафчикам поискать надо, может чего и осталось. )

[Пиит]

... Ошибочка вышла. Не может таким образом определенный Геном показать нам всех наследников Класса, только список фруктов, висящих на одной ветке...

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

Случилось другое, я немного переоценил значение Генома, полагая, что смогу с его помощью производить отбор сразу всех потомком из всех Классов-наследников в одном списке. Не смогу, только представителей одного Класса-наследника, и ДеревоКлассов автоматически переименовывается в ДеревоВидов.
Такую работу Дерева можно увидеть в Проводнике в Окнах. Щёлкаю слева по Каталогу, и справа вижу только Файлы, непосредственно к нему относящиеся, а файлы в подкаталогах на этом уровне просмотра остаются невидимы для глаза. Но ФайловаяСистема имеет иерархическую реализацию, а наша модель по-прежнему остаётся самой что ни на есть реляционной. Список Видов в отборе представляет собой Домен из Видов Генома, и прибавляется как есть на форме списка к списку элементов. Таким образом, всё остаётся в силе, на каждом уровне наследования работаем с данными только выбранного Класса и его Предков, и там же можем производить выборки по Видам потомков, не обращаясь непосредственно к их ТаблицамБД.
Домен, к слову, в узком смысле - это множество уникальных значений одной колонки ТаблицыБД, в широком смысле - множество уникальных значений одного ТипаДанных в Базе. Это термин от СУБД, общепринятый в современных РБД. Есть и в V7 системный специальный метод для работы с подобными множествами, а именно ПолучитьЗначениеОтбора(ИмяОтбора, СписокЗначений, ДатаНач, ДатиаКон), очень жаль, что он работает только с Документами, не понимаю причин для обделения Справочников такой замечательной возможностью.

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

МногоуровневыйСправочник V7 содержит в себе несостоятельность с точки зрения  реляционной модели. Посмотрите в ТаблицуБД, записи Элементов практически все заполнены информацией, а для Групп как правило используются несколько полей типа Код и Наименование. Лично я не вижу ни одной причины для такой реализации. Не только природа не терпит пустоты, но и дедушка Кодд, если узнает об этом безобразии, перевернётся на другой бок от негодования.

Тем не менее, и в V7 есть один ПрикладнойОбъект, построенный по всем канонам, с некоторыми оговорками, это ПланСчетов. Именно ПланСчетовV7 являет собой пример "относительно" правильной СтруктурыДанных, в которой все поля заполнены заявленной информацией, и все элементы равноправны в контексте возможного разделения их на подмножества. "Относительно" здесь имею в виду не в негативном ключе, а принимая во внимание специфику ПрикладногоОбъекта.
В V8 появилась разновидность Справочника СИерархиейЭлементов, который я также могу отнести к правильным СтруктурамДанных.

А представляют собой эти оба ПрикладнымОбъекта не что иное, как Деревья Структур, соответствующих своему назначению. Подобные ПрикладныеОбъекты я считаю необходимым отделить от Справочников в собственную ветку Метаданных.

Правильное же построение МногоуровневогоСправочника аля V7 требует двух СтруктурДанных, Список отдельно, Дерево отдельно, а в структуру Элемента добавить индексируемый Реквизит типа Дерево соответсвующей структуры, со своими Кодом и Наименованием. Здесь и пригодится нам новая ветка ПрикладныхОбъектов, основанная на Деревьях. В этом случае и можно будет говорить о состоятельности как реляционной, так и структурной.
Есть в этой реализации некоторые вопросы с отображением Групп и Элементов в общем Списке, но это деталь техническая. А вот принципиальная штука здесь - возможность наделить Справочник сразу несколькими Деревьями, не говоря уже о присутствующем по умолчанию системном ДеревеВидов...

[Forum123]

А вот принципиальная штука здесь - возможность наделить Справочник сразу несколькими Деревьями, не говоря уже о присутствующем по умолчанию системном ДеревеВидов

Не скажу, что нынешние СУБД  несовершенны.
Они спроектированы профессионалами и пригодны для решения многих задач, но не пригодна для задач в которых требуется использавание динамических объектов с динамических наборов свойств.
Для такого рода задач реляционная модель не годится, а таковых задач много , так как в этом мире даже двух одинаковых снежинок не бывает (в реляционной модели все снежинки одинаковы).

Поэтому ИМХО.
Не нужно зацикливаться на справочниках, документах, ...
Должна быть возможность создания и использования любой сложности объектов.
У меня это одна из веточек в разрабатываемом API.
Это и есть ответ на то, почему никогда не было желания разработать а-ля 1С (а вот конфигурации 1С удобно использовать для отладки части API).

[Пиит]

... Случилось другое, я немного переоценил значение Генома...

Да, коллеги, кто ещё не понял, рождение Генома состоялось здесь и сейчас, на этом форуме, на ваших глазах. Варит ещё котелок. Так далеко я ещё не продвигался в этой модели. Напомню, что это вторая модель уложения структур данных в Таблицы, ссылочная. Давным-давно, когда я впервые сел за тетрадки по этой теме, я допетрил до первой модели, ставшей уже христоматийной, на субтаблицах и супертаблицах, покрутил и выбросил как неперспективную, не дающую в полной мере положить в таблицы СтруктурыДанных любого уровня сложности. А во второй модели, на уровне свойств Рода. я пошёл по тупиковому пути, ввёл тогда Потомка, превратил Род в двусвязный список, и не знал, чего с этим делать. Геном представлялся тогда мне суммой ID всех членов Рода, он рос по мере Эволюции, и ни в какое поле не мог быть положен.

Вот поэтому я намедни и предупреждал своего нетерпеливого читателя, что готовой Концепции у меня в кармане нет. Вот она, рождается на ваших глазах.

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

У школьных учителей, прям у всех, есть одни и те же словечки и целые фразы. Так, например, любой учитель то и дело задаёт вопрос Классу: "Всё понятно? Вопросы есть?". Класс конечно отвечает: "Нееет". Учитель с грустью: "Это плохо, что вопросов нет", и добавляет: "Если вопросов нет, запишите домашнеее задание...".
Почему же с грустью? Потому что, если вопросов у Класса нет, значит плохо объяснил, или никто не слушал.

Здесь я уже приглашаю вас, коллеги, подключаться к этой дискуссии, уверен, что одна голова хорошо, а два IQ таки пара.

При первом же предметном разговоре я сверну здесь свои биографические простыни, и развешу их по-дальше отсюда, по-ближе к Пушкину, а эта ветка останется исключительно как место для развития модели Прикладного Объектного Программирования в Реляционных Базах Данных.
Почему так всё большими буквами? Потому что здесь я рассматриваю вышеописанную обрывками на 12-ти страницах одну Модель, и никакие другие, ни иерархические, ни другие фантазии. Только циркуль и линейка, только ООП и РБД в контексте ПОП 1С.

И разрешите вас таки поздравить, в 2023 году в стандарте SQL проклюнулась поддержка Графов.
Нам ещё не поздно сделать революцию, буржуины ещё топчутся.

[trdm]

Ну раз ты тут Эйнштена приводишь, то возможно всякое, вплоть до искревления пространства/времени, в отдельной взятой комнате...

В панельных хрущёвках расхождение стен в комнатах запросто 10 см. и более бывает.

Я и сам строил, можешь не рассказывать.
жить не мешает, просто больным рвет шаблоны.

[Пиит]

... Возможно, спецы Компании тоже остановились где-то на этом месте, и так появился МногоуровневыйСправочник, с его ParentID, как элемент несостоявшегося наследования данных в V7...

Я более чем на 100% уверен в том, что Платформа изначально задумывалась как полноценная ООП-система. Но что-то пошло не так. Глядя на реализацию V7, можно предположить, что произошли изменения в составе команды разработчиков, и превратилась программа в эдакое письмо из Простоквашино. Начал писать ДядяФёдор: "Дорогие мои Родители...", а продолжил уже некий Шарик, у которого "то лапы ломит, то хвост отваливается". Не исключено, что был там и своего Рода Матроскин, со своей коровой и молоком изо всех умывальников, и в результате Лохматость Платформы таки изрядно повысилась.
ДядяФёдор был толковым парнем, знал не только ООП, но и SQL-3, по крайней мере о СубТаблицах и СуперТаблицах имел хорошее представление.

А как бы выглело то Дерево Классов, все Справочники, со всеми своими Потомками, от Элемента до Ботинка, в классической схеме, в СуперТаблице? Проще простого, друзья мои. Создаю СуперТаблицу [ID, ParentID, Код, Наименование], это тот самый БазовыйКласс, она же СубТаблица "Элементы". Далее, хочу ТМЦ, добавляю в СуперТаблицу [, Цена, ЕдИзм], получаю СубТаблицу "ТМЦ", считая от начала, от ID, таки СубТаблица - это таблица воображаемая. И так далее, продолжаю добавлять все Ревизиты всех Потомков, до самого Ботинка, с его[,Размер,Цвет]. Таким образом, СуперТаблица может вместить в себя всё и вся, все Виды Спраочников, и ОсновныеСредства, и Сотррудники и т.д. А в этой каше всех Реквизитов всех Справочников могут разобраться только Метаданные с Класссами, построенными на СубТаблице, представляющкй из себя, повторю, логически связанный набор колонок СуперТаблицы, вне зависимости от их порядка в ней и возможного повторения в других СубТаблицах. Так, каждый Класс, каждая СубТаблица обязательно содержит в себе колонки своих Родителей, вплоть до Базового Класса, поля ID, ParentID, Код и Наименование. Таким образом, в одну СуперТаблицу помещается вся ветвь Метаданных Справочники, с реализованным Наследованием данных и даже их Эволюцией.
А ID здесь является общим для всех Элементов, и уникальным для каждого Ботинка, идентификатором всего и вся на всех уровнях наследолвания. Красиво? Очень.

Но как же из этой каши выбрать наши Ботинки? И что же такое этот ParentID?
Вот, как мне кажется, на этом вопросе споткнулся  проект, ДядяФёдор крепко задумался.
Если в этой СуперТаблице ParentID есть некая ссылка на Родителя, то на кой она такая вообще нужна, если Родитель уложен в одной и той же записи, что и его потомок, и имеет тот же ID? И где взять этот ParentID, если его не в даже в Базе. Но Меданных то есть, имхо, это не проблема, Перечислений тоже нет в Базе, но тем не менее, IDы их используется, как ни в чём не бывало.
Я вот не сомневаюсь, что такое ParentID, он же OBJID, он же Вид, он же ПолуГеном - это идентификатор Вида Справочника, и определив его таким образом, можно по щелчку производить отбор по индексу любого множества потомков любой СубТаблицы, по её колонкам, заданным в Метаданных.

Что же случилось с ДядейФёдором, отчего не дожал этот вопрос? Сложно сказать, не верю что не допетрил, возможно на самом деле уволился из Компании, а может и просто разочаровался в СубТаблицах. Ведь недостатки в схеме есть, СуперТаблица огромна, и вширь и вниз, и реструктуризация её по мере роста может представлять из себя уже существенную проблему, учитывая возможное количество полей и записей. И физический размер такой таблицы, как мы знаем, не бесконечен, и на количество записей, и даже на свой объем.
Но я знаю одно - ДядяФёдор поработал таки ещё некоторое время над проектом, он стал рассматривать, помимо классической схемы наследования, и ссылочную. Это та самыя конструкция Документов, 1SJOURN и DH, это наследование Инкапсулярное, и Классы Документов оказались все в своих таблицах БД, проклюнулся даже CHILDID. А вот таблицы DT являют собой классическое Вложение множественных структур, и здесь проявляется некое смешаное использование двух концептуально разных подходов для ООБД. А термин OWNER позволяет мне предположить, что ДядяФёдор мог планировать, помимо наследования, и возможность Вложения СтруктурДанных в своём детище.

А дальше ДядяФёдор вероятно покинул проект, а может просто не справился с компилятором ООП, или был банально ограничен временем и другими Ресурсами, вынужден был наконец на чём-то остановиться, ведь это вам не Казанский университет, а российский IBM, и результат работы таки вынь да полож. Матроскин хотел молока. Как бы то ни было, имхо дальше проектом руководил Шарик. Шарик был старым псом, но тоже умным, по своему, возможно даже это он спроектировал V6, очень уж любил он Группы в Справочниках, но вот ООП никак не мог уложить в свои полуШария, поэтому в дальнейшем вместо СуперТаблицы появился МногоуровневыйСправочник. Названия полей менять не стали, приемственность-на, да и слишком много кода надо было переписывать. Так остались в Платформе и ParentId, и Owner, но суть этих понятий кое-где претерпела сильные изменения. Стали появляться новые термины, такие как ParentExt, он же Владелец Подчинённых Элементов, и прочие. Заметьте, не Owner, а ParentExt. В общем, Лохматость Платформы заметно повысилась.

ДядяФёдор заложил в проект даже больше идей, чем реализовали за все последующие годы. Один только термин VERSTAMP чего стоит, имхо это Версионность в её зачаточном состоянии. В Константах, по другому в ПериодическихРеквизитах есть такой реликт - OBJID, я его уже здесь поминал, в контексте ParentID, вот это и есть оно, несостоявшееся ООП в V7.

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

[Пиит]

... А термин OWNER позволяет мне предположить...

У меня тоже, походу, лохматость повысилась.
Откуда я взял OWNER в семёрке?

[Злоп]

Всю свою жизнь проводит в мечтах. Мечты Обломова подразумевают тихую спокойную жизнь с красавицей-женой и детьми. Он мечтает поехать заграницу, путешествовать с другом и своей возлюбленной, наладить быт в своем имении. Как может заметить читатель, все его мечты вполне осуществимы. Нужно лишь немного приложить усилий. Но проблема мечты Обломова состоит в том, что главный герой не хочет прикладывать даже малейших усилий, чтобы добиться желаемого результата.
На некоторое время его вдохновляет своей бурной деятельностью друг детства Андрей Штольц. Он берет Облоиова с собой на различные приемы, знакомит с интересными людьми. Но Обломов очень быстро устает от такой деятельности, ему кажется все происходящее слишком сложным. Он придумывает тысячу причин, чтобы не видеться со своей когда-то обожаемой Ольгой. В одной из бесед Ольга спрашивает Обломова: "Отчего погибло все?... Ты добр, умен, нежен, и благороден... и...гибнешь! Что сгубило тебя?" Он в ответ прошептал: "Обломовщина"

[Forum123]

Я более чем на 100% уверен в том, что Платформа изначально задумывалась как полноценная ООП-система.

Семёрка прекрасно дружит с OLE и Net.
OLE позволит в семёрку добавить новую функциональность (в т.ч. объекты).
В Net вагоны разработанных и отлаженных проектов, которые можно подружить с семёркой.
Не сложно и ответить на вопрос почему мало кто расширяет семёрку.
Всё просто - ХАЛЯВУ ЖДУТ!

[Пиит]

...Всю свою жизнь проводит в мечтах. Мечты Обломова ...

Пишите, Че, пишите, не нужно репостить.
Я знаю, что и Вам есть о чём рассказать.
Но должен Вас предупредить, это не просто.

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

Я не писал никогда серьезно ни стихи, ни прозу, до одного не очень прекрасного дня, когда стихи начали выходить из меня, что называется, по-взрослому. Я даже могу назвать этот день, когда всё началось. Нет, я не помню дату, год, я помню момент, событие, которое на меня, скажем так, оказало некоторое влияние. Это была трагическая гибель Владислава Галкина, и вечером по телеку в новостях показали небольшой сюжет. Похороны, могила, стоит Борис Галкин, и плачет... Несколько секунд как целая вечность. И я заплакал тогда вместе с ним... Я и не знал, что Владислав - сын Бориса, пришёл в себя, полез в гугл, а там - гавно на каждом углу, Владислав то, Владислав сё, дебошир, пьяница и сам виноват... И тогда я с какого-то хрена сел за стол, взял ручку, и начал писать. Этот стих не закончен до сих пор, не лежат кирпичи на своих местах, и врядли будет закончен когда-либо.

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

Однажды в другой не очень прекрасный день я перестал писать. Но здесь я могу назвать эту дату точно, я её не забыл, и даст Бог, никогда не забуду. Это было 2 мая 2014 года. Вот, в тот день у меня как язык отрезало, с тех пор нет ни желания, ни внутренней потребности в рифмовании мыслей.

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





П.С.:

Пиши, мой друг, пиши!
И ямб, и анапест.
От сердца, от души
Какой угодно текст.

Не верь седым умам,
Не рвись и не спеши.
Пиши, как знаешь сам,
Но только не греши.

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

Пиши о мотыльках,
Про ветер и про птиц,
Держи в своих руках
Всегда чернильный шприц.

Пиши, мой друг, пиши!
Для близких и родных,
От сердца, от души,
Свой самый верный стих.

10.04.2013

[Пиит]

-

[Forum123]

-

Предыдуший пост не относился к Вам лично.
Хороший блог.
Конечно реляционые базы имеют нишу использования.
В мире объектов все виды объекты нужны.
Главное уметь правильно их использовать и не натягивать сову на глобус.

[Пиит]

А давайте, я напишу на эСке Дуум. Не сразу, начну с малого, с Паинта.

Вот мольберт, ТаблицаБД с числовыми реквизитами [Измерение1, Измерение2, Цвет]. Далее определю составной Индекс Измерение1+Измерение2, позволяющий мне ПолучитьТочку(Х, У) и УстановитьТочку(Х, У, Цвет).  Таким образом я получил в распоряжение двухмерное Пространство, в котором могу малювать что хочу по заданным координатам. А дальше дело техники, процедурное программирование, хошь отзезок, нарисую отрезок, хошь окружность - пожалуйста, а хошь и залью это всё любыми красками. Заметьте, это не бинарный файл, и не в Текст уложена Картинка, а вполне реляционная модель. Здесь можно и улыбнуться, типа вы раньше о таком не знали.

А на кой же мне такой Паинт, с форматом BMP и гигабайтами в базе? Пока не знаю. А может, Корэл лучше будет?

Но тут процедурами не обойтись, здесь нужны уже Классы, например, Точка, МножествоТочек, Отрезок, Окружность и так далее, и каждый из них имеет свои уникальные свойства и методы построения. Мы же знаем, что Окружность - это МножествоТочек, равноудалённых от одной Точки, и определяется Центром и Радиусом, вот и свойства Объекта пожалуйста. И Точка здесь уже не просто Цвет, а Структура, [Цвет, Следующая, Предыдущая], позволяющая включить её в произвольное МножествоТочек, в любой связный Список. А двухмерное моё Пространство Паинта уже станет не более, чем проекцией МножестваОбъектов, зависимой от и от состава, и от заданных значений их свойств. Так, изменив Радиус одной всего Окружности, необходимо отрисовать заново нашу Картинку. Что это, если не ВекторнаяГрафика?

А чего я остановился? Давайте добавим третье [Измерение3], и получим трёхмерное Пространство. Автокад? Пока не знаю. Знаю, что измерения могу определить с любой степенью точности, хоть 0.000001, и конечно, плюс отрицательные значения. Могу ввести в Пространство ТочкуОтсчёта и три ортогональных Вектора, и создавать проекции МножестваОбъектов на любую заданную Плоскость.

Может это уже 3D-Макс? В общем, чем-то напоминает. Но я беру это МножествоОбъектов, загружаю в ПЗУ, и придаю им направление движения и вращения, осталось только Флинну Таггарту текстуры на жопу натянуть.

Вот вам, друзья, и Реляционный Дуум. Мне он даром не нать, и недаром тем более, я подводил к другому.

Есть в семёрке такой замечательный Объект, Регистр назывется. А вы не пробовали в нём задавать Изменения как Число? А Конфигуратор позволяет. Жаль, руками его с места не сДвинешь, тут помощник нужен. А само слово "Измерение" откуда у Компании взялось? Конечно, сущность-то многомерная типа, но Измерения Числовые у нас в Геометрии, а в Пространствах Алгебры и ТеорииМножеств они могут быть заданы произвольным Множеством элементов, например теми же Товарами или Партиями.
Назвать можно как угодно, и Регистром, и Пространством, и Массивом и даже N-мерной Функцией, главное - не ограничивать Платформу никакими идеологиями, и коль взяли уже на вооружение такой молоток, покрутите его в руках, посмотрите на него с разных сторон, может, и Дуум не такая уж фантастика на втором этаже...