Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, savinov, Вы писали:
S>>Думаю, что от происхождения идеи ничего не зависит. Важна просто сама идея. V>В серьёзной научной работе в самом начале всегда прямо или косвенно описывается происхождение идеи. Именно такой preface и позволяет определить контекст, к который нужно поместить описываемую дальше измышлятину. Вне контекста в научном мире ничто не существует.
Да, известно, что в научном мире очень не любят (мягко говоря), когда что-то или кто-то возникает из вакуума (поскольку это приводит к напрягу, которого никто не любит). Но в данном случае у идеи действительно нет происхождения в "научном " смысле, т.е. нет непрерывной истории развития. КОП развился из реальной потребности на низком уровне, и общих предположений о принципах функционирования систем на высоком уровне.
S>>Странно, почему тогда нет примеров, если КОП возникла как раз по первому варианту развития? V>Тогда нужно просто вспомнить, с чего всё начиналось
Так долго не живут Да и, как уже упомянул, нет смысла, поскольку нет цели придать этой работе "научный" характер в традиционном смысле этого слова (в смысле, это не главная цель).
V>>>Желаю удачи в выдумывании убедительных иллюстративных примеров. Придумаете, заходите ещё. S>>Спасибо. Если появятся, то обязательно зайду.
V>Подкину идейку. Информационные сущности бывают двух видов: V>1. Объекты — это то, что может обладать идентичностью (и, следовательно, иметь какой-либо OID). V>2. Не-объекты — это такие сущности, которые ничем, кроме как своим содержимым, не идентифицируются. Например: размер заработной платы, длина отрезка, наименование товара.
Сразу скажу, что разделение на объекты и не-объекты очень сильное предположение, и оно мне очень нравится. Хотя бы потому, что именно так делается в КОП. Правда в КОП не-объекты это в первую очередь ссылки, задача которых состоит в представлении объектов (хотя никто не запрещает использовать их для других целей). Конечно, сила идеи вовсе не в том, что мы допускаем передачу по значению, а в том, что устанавливаем формулируем такое разделение на объекты и не-объекты в качестве первичного предположения, а потом выводим из него следствия. В КОП такое разделение это частный случай свойства двойственности, которое играет важную роль также в концептно-ориентированной модели данных .
V>Такие не-объекты имеют важное свойство: они не умеют существовать самостоятельно. Они всегда существуют в рамках контекста (который, конечно, уже является объектом). Самое смешное, что не-объекты не обязательно принадлежат примитивным типам данных. Например, всякий суммовой показатель, кроме собственно числового значения, как правило, характеризуется валютой. Соответственно, натуральный показатель — единицей измерения. Даже со строками не всё так просто: в принципе, строковое значение может характеризоваться языком, на котором она написана.
Да, ссылки (не-объекты) в КОП имеют любую структуру и функции, поскольку описываются классом. Т.е., изначально предполагается, что есть классы ссылок и классы объектов для описания структуры и функций двух типов сущностей.
V>Пример: увеличить зарплату (поле Salary) сотрудника emp на increase USD. Предполагается, что сотрудники, кроме всего прочего, характеризуются валютой взаиморасчётов (SalaryCurrency) V>"Обычный" подход, в котором не-объекты не имеют структуры и пассивны: V>
emp->>Salary += ConvertMoney(increase, new Currency("USD"), emp->SalaryCurrency);
V>
V>Проблема в том, что такой метод не является себя-дурака-устойчивым. Рано или поздно забудется, что денежку нужно конвертнуть, и появится строчка типа: V>
emp->>Salary += increase;
V>
V>, которая будет исправно работать до тех пор, пока все зарплаты исчисляются в USD. При появлении первой рублёвой зарплаты система заглючит. V>Можно, конечно, числовое поле Salary завернуть в программный интерфейс, но если таких числовых полей сотни, то это ж будут не классы, а большие коллекции маловразумительных методов. И, в конце концов, кто-нибудь что-нибудь всё равно забудет.
V>А можно было бы и так: V>
V>emp.Salary += Money(increase, new Currency("USD"));
V>
V>При этом Salary — это, на самом деле не просто числовое поле, а некая обманка, физически состоящая из двух полей (значение и валюта) и принадлежащая к специальному классу Money, на котором определены арифметические операции, которые при необходимости сами конвертят валюты.
Я вижу в этих рассуждениях следующий прокол. Сперва в качестве основного свойства (аксиомы) не-объектов устанавливается их способность представлять самих себя. А далее в качестве желаемого свойства (цели) описывается поведение, которое не имеет особого отношения к способности не-объектов передаваться по значению. Действительно, в данном примере нет ничего, что требовало бы от зарплаты быть не-объектом. Т.е. меня совершенно непонятен переход от данного примера (use case) к выводу о необходимости иметь не-объекты вообще и их способности передаваться по значению в частности. Этот шаг в рассуждениях надо бы описать детально.
V>Что характерно, эти самые не-объекты — это даже не структуры в привычном понимании этого слова. Например, одно "физическое" поле Currency (валюта взаиморасчётов) может обслуживать и размер зарплаты, и премиальную ставку, и баланс лицевого счёта сотрудника.
Я бы выделил в качестве первого свойства, которое необходимо как-то обеспечить, это способность сущностей (пока мы не говорим об объектах или не-объектах) относиться к определенной категории, что может существенно изменить операции с ними. Например, могут быть валютные сущности, что приводит к тому, что операции с определенными полями выполняются с конвертаций в предположении, что где-то можно найти текущую валюту. Заметим, что включение в такую категорию это как раз то, что называется crosscutting concern (пронизываещее свойство), поскольку многим разным классам можно приписать одну категорию. Скажем, в категорию "валютный объект" можно включить классы Account, Customer и др. классы. В результате одни и те же правила пересчета должны быть описаны в одном модуле, но применяться в разных.
Ну и опять же повторю, я не вижу как мы приходим к необходимости разделения на не-объекты и их свойству представлять себя самих.
V>------------------- V>Короче, дарю этот иллюстративный пример. Если, конечно, он окажется КОПу по зубам.
В КОП главное предназначение не-объектов состоит в представительских функциях, т.е. это ссылки. Соответственно, главным вопросом является то, как осуществляется это представление и как осуществляется доступ. Надо понять принципы сосуществования и взаимодействия объектов и ссылок, поскольку только вместе они могут сделать что-то полезное. Так что в этом смысле это пример не совсем для КОП, хотя я не исключаю, что его можно как-то решить с помощью КОП. В основе решения я вижу как-то приплести средства перехвата для определенного класса объектов ("валютные объекты"). Перехватчик собственно и реализует функции автоматической и принудительной конвертации валюты или учета др. параметров (сборы, наличие данной валюты и т.п.) Здесь можно использовать АОП или прокси или еще что-то вроде этого. Сама валюта может храниться либо в объекте либо в ссылке (оба варианта возможны).
V>Саму же идею не-объектов не дарю. Если эта нива ещё никем не вспахана, то пусть она будет моей
Хотя разделение на объекты и не-объекты это правильный ход, но конечно, само по себе это имеет мало смысла. Нужен какой-то механизм, какая-то операционная семантика. Иначе всегда можно сказать, что это уже существовало. Например, всегда была передача по значению. Например, в КОП конкретно описывается как работают ссылки и объекты в рамках единого механизма.
Здравствуйте, savinov, Вы писали:
AVK>>Очевидно нет. Если с помощью А можно реализовать идею столь же эффективно, сколь с помощью нового подхода, то новый подход не нужен. По моему это очевидно. Не потрудитесь ли обосновать, в чем здесь демагогия.
S>Демагогия в отсутствии точных критериев оценки (эффективности и простоты).
Демагогия не может в этом состоять. Демагогия тем и отличается, что использует приемы, не относящиеся к существу спора. Ты же задаешь вопросы именно что по существу.
Возвращаясь к твоим вопросам — во-первых точные критерии таки есть и немало. Во-вторых в большинстве случаев квалификация приличного программиста позволяет оценить эффект не применяя формальных оценок. Было бы что оценивать.
S> Слова "можно реализовать" или даже "можно реализовать лучше, проще и эффективнее" имеют весьма общий характер.
Они имеют весьма конкретный характер, выражающийся в потраченных на разработку и поддержку человекочасах.
S> И спорить в такими утверждениями нельзя.
Вот если принять твою идею о том, что вобще ничего нельзя оценить, вот тогда действительно ни спорить, ни вобще ничего разумного делать нельзя.
S> Например, Ява в 10 раз медленнее, чем С++, ну и что?
Например вы не знакомы с предметом и говорите глупости.
S> Там существенно меньше возможностей, ну и что?
И это тоже неправда.
S> Простота и красотва — вот единственный критерий, но он неформальный.
Единственный критерий это ресурсы. Потраченные и полученные. Остальное от лукавого. Впрочем, красоты и простоты вы тоже не продемонстрировали. Никто пока что в ваших словах никакой красоты не увидел. И, сдается мне, проблема не в тех, кто не увидел, а в ваших идеях.
AVK>>Нет, не все. Это значительно сложнее и код получается менее качественным. Так что вперед, показывать, что КОП может выразить то или иное полезное решение лучше, чем любое из существующих средств.
S>Про виртуальные методы я как раз понимаю, S> но Вы никогда это не докажете человеку, который привык реализовывать все вручную, и тем более, если для этого есть библиотека, и уже подавно, если он сам этого не хочет.
Демагогия off, примеры в студию.
AVK>>А это уж точно демагогия. Объяснять почему?
Видимо объяснять не надо. И то хлеб.
S>Это как раз Ваша логика, которую я привел для иллюстрации демагогии.
Демагогия — переход на личности, попытка оправдать свою демагогию поведением собеседника.
S> Я уже как-то опоминал, что проблема состоит в том, что один конкретный человек обычно имеет свою излюбленную область, где он действительно является экспертом.
Демагогия — переход с объекта на субъекта.
S>Если взять пример с реляционной моделью, то знаете скольким людям она действительно не нужна,
Демагогия — доказательство на аналогиях.
S>На этом (и большинстве других) форумах обсуждение как раз и сводится к религиозным боям не на жизнь а на смерть, где главным аргументом является "я сам с помощью метода А сделаю все лучше, чем ты предлагаешь с помощью метода Б".
Демагогия — факты, не относящиеся к предмету спора.
S>Что касается меня, то я в таких спорах не участвую ввиду их бессмысленности (поскольку это демагогия).
Просто вранье. В ваших постах даже для этого форума демагогии более чем.
S>Если Вы хотите дискуссии по существу, то задавайте вопросы по существу.
Демагогия — полное игнорирование всех заданных вопросов. По существу. Списочек вопросов привести?
S> Вопрос по существу отличается от пустого вопроса наличием хотя бы одного-двух терминов, специфичных для обсуждаемого вопроса.
Демагогия — собственное определение, не имеющее ничего общего с реальностью. По сути перевод на спор о терминах.
S> Вопсро типа "докажите мне, что это лучше" таких терминов не содержит.
Тем не менее это вопрос по существу. Но для тебя я его переформулирую, чтобы спятаться за собственными терминами нельзя было:
Докажи, что твоя парадигма, лучше парадигм, которые широко распространены (ООП, ФП, ЛП) в плане:
а) Скорости написания кода
б) Сложности поддержки кода
в) Читаемости кода
Термины, "специфичные для обсуждаемого вопроса" я жирненьким выделил.
S> Кроме того, это претензия, а не вопрос.
Это вопрос, даже не сомневайся. Народ тут с нетерпением ждет на него ответа.
S> Так что я могу только еще раз попросить: задавайте вопросы по существу предлагаемого механизма.
Ну ты понял.
S> Если у Вас нет времени и/или желания вникать в детали, то просто не завайте вопросов и все.
Демагогия — попытка остаться в споре с последним словом.
Здравствуйте, savinov, Вы писали:
S>...поскольку нет цели придать этой работе "научный" характер в традиционном смысле этого слова (в смысле, это не главная цель).
Тогда нужно забыть слово "диссертация". Кстати, и для продвижения идеи вне рамок научного мира тоже неплохо определиться с контекстом. Чисто для того, чтобы быстрее народ втыкался.
V>>2. Не-объекты — это такие сущности, которые ничем, кроме как своим содержимым, не идентифицируются. Например: размер заработной платы, длина отрезка, наименование товара.
S>Сразу скажу, что разделение на объекты и не-объекты очень сильное предположение, и оно мне очень нравится. Хотя бы потому, что именно так делается в КОП. Правда в КОП не-объекты это в первую очередь ссылки, задача которых состоит в представлении объектов
В моей трактовке не-объекты нужны совсем не для того, чтобы представлять объекты. Например, не-объект Адрес не даёт доступ к объекту Клиент, на котором он паразитирует. Он даёт доступ к своим полям (которые, кстати, одновременно являются также полями класса Клиент) и реализует всякий вкусный программный сервис (например, формирует адресную строку для Веб2.0-сервиса, отображающего кусок карты). А ведь адрес может сидеть в объекте Клиент несколько раз (поля ГородЮр, ГородФакт, УлицаЮр, УлицаФакт и т.д.). В таких случаях, конечно, хочется не копиблочить программные куски, а реализовать объект Адрес один раз, и просто "подключать" его к разным полям.
И речь идёт не о том, что нам хочется передавать не по ссылке, а по значению. Совсем наоборот! Нам хочется организовывать доступ по ссылке к информационной сущности ("не-объекту"), которая сама по себе какой-то единой ссылки не имеет (по причине пожизненного паразитизма), но внутреннюю структуру и программный интерфейс таки имеет.
S>Да, ссылки (не-объекты) в КОП имеют любую структуру и функции, поскольку описываются классом. Т.е., изначально предполагается, что есть классы ссылок и классы объектов для описания структуры и функций двух типов сущностей.
Вот, собственно, это меня и заинтересовало — возможность создавать и использовать ссылки на то, на что обычных ссылок в принципе не может быть создано (не-объект ни на каком этапе своей жизнедеятельности не должен превращаться в объект). Почему обычная ссылка не может быть создана? Да потому, что создание обычной ссылки — это придание OID, а придание OID не-объекту — это уже принципиально некорректная операция.
S>Действительно, в данном примере нет ничего, что требовало бы от зарплаты быть не-объектом. Т.е. меня совершенно непонятен переход от данного примера (use case) к выводу о необходимости иметь не-объекты вообще и их способности передаваться по значению в частности. Этот шаг в рассуждениях надо бы описать детально.
Зарплата, не обладает свойством идентичности. Две зарплаты равны, если у них равны размер и валюта. Что не скажешь, например, о людях. Два человека являются всё-таки двумя разными человеками, даже если у них совпадают фамилии, имена, отчества, и даже цвет глаз. И всё потому, что люди обладают свойством идентичности, а их зарплаты — нет. За более подробным описанием того, что такое идентичность, вынужден отослать к классике жанра: Гради Буч, Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Конкретно, глава 3.1 "Природа объекта".
V>>Что характерно, эти самые не-объекты — это даже не структуры в привычном понимании этого слова. Например, одно "физическое" поле Currency (валюта взаиморасчётов) может обслуживать и размер зарплаты, и премиальную ставку, и баланс лицевого счёта сотрудника.
S>...Скажем, в категорию "валютный объект" можно включить классы Account, Customer и др. классы. В результате одни и те же правила пересчета должны быть описаны в одном модуле, но применяться в разных.
Не всё так просто. Если Account действительно может быть валютным, то Customer или Employee валютным быть не может! Это ж фигня какая-то — валютный сотрудник. То, что у класса есть свойство Currency, не означает, что этот класс является "валютным". Это просто означает, что некоторые из его числовых атрибутов могут быть выражены в валюте.
S>Хотя разделение на объекты и не-объекты это правильный ход, но конечно, само по себе это имеет мало смысла. Нужен какой-то механизм, какая-то операционная семантика. Иначе всегда можно сказать, что это уже существовало. Например, всегда была передача по значению. Например, в КОП конкретно описывается как работают ссылки и объекты в рамках единого механизма.
Короче, я понял, что КОП ориентирован только на переопределение встроенного механизма доступа по ссылке к объектам (что, впрочем, мало интересует, т.к. существующий механизм устраивает, а кому хочется извращений, тот юзает smart pointers), а в случае не-объектов пасует. Или всё-таки не пасует?
Здравствуйте, Voblin, Вы писали:
V>Короче, я понял, что КОП ориентирован только на переопределение встроенного механизма доступа по ссылке к объектам (что, впрочем, мало интересует, т.к. существующий механизм устраивает, а кому хочется извращений, тот юзает smart pointers), а в случае не-объектов пасует. Или всё-таки не пасует?
По поводу не-объектов не могу сказать с определенностью, поскольку не понимаю до конца идею, а особенно актуальность проблемы. Если что придет в голову, то поделюсь.
А умные указатели имеют целый список проблем (за полноту не ручаюсь):
В объявлении переменных надо указывать два класса: класс ссылки и целевой класс. Экземпляр класса ссылки явно создается и инициализируется. Налицо усложнение и нарушение принципа полной прозрачности. Одно крайне неприятное следствие в том, что, если я захочу потом изменить класс ссылки на другой, то надо менять весь код.
Умный указатель (обычно) хранит прямой указатель на целевой объект в своем поле. А что, если объект будет перемещен. Это плохо, поскольку ограничивает степень и возможности опосредования.
Невозможность перехватить нужные методы, а способность реализовать только общее опосредование в пересмотренном операторе доступа. Кроме того, даже без перехвата не рекомендуется реализовывать методы умной ссылки, поскольку это может легко привести к путанице с методами представляемого объекта.
Реализация слоеных ссылок еще более сложна и запутанна, а потому практически не применяется.
Поскольку прямая ссылка на объект возвращается оператором доступа, то это приводит к тому, что опосредование не является симметричным. Мы можем вставить промежуточный код до вызова целевого метода, но не после него. Часто же надо выполнить операции после доступа, например, очистка.
Для каждого целевого класса генерируется (с помощью шаблона) один класс умной ссылки, что не очень красиво. Если надо представлять 100 целевых объектов, то будет сгенерировано 100 классов ссылки.
Этот механизм опирается на специфику С++ и шаблоны, что существенно ограничивает его использование. Но даже в С++ они используются в весьма ограниченных целях для совершенно конкретных задач.
Здравствуйте, AndrewVK, Вы писали:
S>> Простота и красотва — вот единственный критерий, но он неформальный.
AVK>Единственный критерий это ресурсы. Потраченные и полученные. Остальное от лукавого. Впрочем, красоты и простоты вы тоже не продемонстрировали. Никто пока что в ваших словах никакой красоты не увидел. И, сдается мне, проблема не в тех, кто не увидел, а в ваших идеях.
У меня такое ощущение, что я общаюсь с новым русским. И по форме и по содержанию.
AVK> Докажи, что твоя парадигма, лучше парадигм, которые широко распространены (ООП, ФП, ЛП) в плане:
Стучать по столу и требовать ты у заказчика можешь, когда заплатишь, а здесь ты можешь вежливо попросить что-то втолковать, если не можешь разобраться самостоятельно.
AVK>а) Скорости написания кода AVK>б) Сложности поддержки кода AVK>в) Читаемости кода[/q]
Ты хоть примерно представляешь, как может быть оформлен ответ на твои вопросы? Если нет, я подскажу: это может занять 10 лет и тома текстов (книги, статьи и т.п.) Или тебя сертификат истинности интересует?
AVK>Термины, "специфичные для обсуждаемого вопроса" я жирненьким выделил.
Это термины, которые "специфичны" для любого подхода, причем не только в программировании. Так что видимо у тебя есть серьезные проблемы с пониманием, что есть специфичное и что есть общее.
S>> Кроме того, это претензия, а не вопрос.
AVK>Это вопрос, даже не сомневайся. Народ тут с нетерпением ждет на него ответа.
Говори, пожалуйста, от себя. А кому эта ветка не интересна, тот сюда просто не заходит. А в твоем случае мне вспоминается поговорка: "Мыши плакали, кололись, но продолжали жрать кактус." Если КОП тебе не нравится, то просто игнорируй эту ветку и не мучай себя и не разводи демагогию. Как говорится, не нравится — не ешь. Ну а если хочется все-таки понять, так читай текст и задавай вопросы по существу работы предложенного подхода.
Я сейчас приведу несколько тривиальных утверждений, которые мог бы написать несколько лет назад, без всякого отношения к теме, но которые мне кажутся здесь весьма уместными.
Кратко, как я понял (спроецировал на понятное мне) про КОП:
Есть объекты, и есть ссылки на них и есть пространства их жизни. На один объект возможны разные ссылки, реализующие разные его представления и разное поведение, которые валидны в разных (каждая в своём), возможно пересекающихся слоях и контекстах.
Естественно, теоретически, всё можно реализовать имеющимися средствами, но:
Результатом новой парадигмы может оказаться появление практической возможности для создания программных решений действительно сложных и объёмных проблем человеком, или коллективом людей. Это весьма достойная цель, и очевидно, что преимущества метода, ещё довольно сырого, предназначенного для серьёзных проектов — весьма не просто (на мой взгляд, так элементарно, но мне лень ) продемонстрировать на простых примерах.
Сейчас такие задачи, которые не решаются из-за своей сложности (многоплановости) и ограниченности имеющихся интеллектуальных и временных ресурсов встают всё чаще и повсеместнее.
Подчеркну, что речь не идёт об ускорении и упрощении для разработки и поддержки кода. Речь не идёт о качестве, переносимости и масштабируемости кода. Речь идёт о создании возможности, которой сейчас не существует вовсе, как например практически не существует возможности для написания современной RPG на ассемблере, по сравнению с каким-нибудь скриптовым языком для специального движка.
Здравствуйте, savinov, Вы писали:
S>У меня такое ощущение, что я общаюсь с новым русским. И по форме и по содержанию.
Демагогия — переход на личности, игнорирование аргументов.
S>Стучать по столу и требовать ты у заказчика можешь, когда заплатишь, а здесь ты можешь вежливо попросить что-то втолковать, если не можешь разобраться самостоятельно.
Демагогия — попытка перевести спор в плоскость личных разборок.
AVK>>а) Скорости написания кода AVK>>б) Сложности поддержки кода AVK>>в) Читаемости кода[/q]
S>Ты хоть примерно представляешь, как может быть оформлен ответ на твои вопросы?
Да.
S> Если нет, я подскажу: это может занять 10 лет и тома текстов (книги, статьи и т.п.) Или тебя сертификат истинности интересует?
Меня интересует хоть что нибудь. Пока что полезной информации ты выдал ровно 0.
AVK>>Термины, "специфичные для обсуждаемого вопроса" я жирненьким выделил.
S>Это термины, которые "специфичны" для любого подхода, причем не только в программировании. Так что видимо у тебя есть серьезные проблемы с пониманием, что есть специфичное и что есть общее.
Демагогия — перевод на спор о терминах, переход на личности.
AVK>>Это вопрос, даже не сомневайся. Народ тут с нетерпением ждет на него ответа.
S>Говори, пожалуйста, от себя. А кому эта ветка не интересна, тот сюда просто не заходит. А в твоем случае мне вспоминается поговорка: "Мыши плакали, кололись, но продолжали жрать кактус." Если КОП тебе не нравится, то просто игнорируй эту ветку и не мучай себя и не разводи демагогию.
Демагогия — переход на личности.
S> Как говорится, не нравится — не ешь. Ну а если хочется все-таки понять, так читай текст и задавай вопросы по существу работы предложенного подхода.
Я вопросы задал. Ты ни на один не ответил
Итого — ты полностью перешел на демагогию, так и не ответив ни на один вопрос и не приведя ни одного аргумента. Из чего я делаю вывод — ничего твои выкладки не стоят, очередная попытка высосать из пальца неизвестно что, не обладая ни знаниями в области теории языков, ни какими то действительно интересными идеями.
Я сейчас приведу несколько тривиальных утверждений, которые мог бы написать несколько лет назад, без всякого отношения к теме, но которые мне кажутся здесь весьма уместными.
Кратко, как я понял (спроецировал на понятное мне) про СОП:
Есть субъекты, и есть связи между ними и есть сообщества. С одним субъектом возможны разные связи, реализующие разные его представления и разное поведение, которые валидны в разных (каждая в своём), возможно пересекающихся слоях и контекстах.
Естественно, теоретически, всё можно реализовать имеющимися средствами, но:
Результатом новой парадигмы может оказаться появление практической возможности для создания программных решений действительно сложных и объёмных проблем человеком, или коллективом людей. Это весьма достойная цель, и очевидно, что преимущества метода, ещё довольно сырого, предназначенного для серьёзных проектов — весьма не просто (на мой взгляд, так элементарно, но мне лень ) продемонстрировать на простых примерах.
Сейчас такие задачи, которые не решаются из-за своей сложности (многоплановости) и ограниченности имеющихся интеллектуальных и временных ресурсов встают всё чаще и повсеместнее.
Подчеркну, что речь не идёт об ускорении и упрощении для разработки и поддержки кода. Речь не идёт о качестве, переносимости и масштабируемости кода. Речь идёт о создании возможности, которой сейчас не существует вовсе, как например практически не существует возможности для написания современной RPG на ассемблере, по сравнению с каким-нибудь скриптовым языком для специального движка.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, savinov, Вы писали:
S>>Стучать по столу и требовать ты у заказчика можешь, когда заплатишь
E>Требовать у заказчика, да еще и платить заказчику... E>Это вообще как?
Пардон, очепатка. (Ну смысл, надеюсь, не окончательно потерялся.)
[Контекст вырезан. Субъективно.]
AVK>Я вопросы задал. Ты ни на один не ответил
AVK>Итого — ты полностью перешел на демагогию, так и не ответив ни на один вопрос и не приведя ни одного аргумента. Из чего я делаю вывод — ничего твои выкладки не стоят, очередная попытка высосать из пальца неизвестно что, не обладая ни знаниями в области теории языков, ни какими то действительно интересными идеями.
Ок. Пусть будет так. В любом случае, спасибо за высказанные оценки.
Здравствуйте, savinov, Вы писали:
S>По поводу не-объектов не могу сказать с определенностью, поскольку не понимаю до конца идею, а особенно актуальность проблемы. Если что придет в голову, то поделюсь.
Идея проста до неприличия. Существуют объекты, которые обладают свойством идентичности, характеристиками и поведением. Характеристики объектов тоже могут быть не примитивными (число, строка, ссылка на другой объект*), а тоже иметь внутреннюю структуру (характеристики) и поведение. В конце концов, стандарт SQL99 уже опсывает user-defined datatypes, имеющие внутреннюю структуру. Пример со значением и единицей измерения (в частности, валютой) — далеко не единственный. Ради интереса я взял первую попавшуюся базу данных (Northwind из комплекта поставки MSSQL), поискал там не-объекты, имеющие чётко выраженную внутреннюю структуру, и выяснил, что в состав не-объектов входит порядка 25% полей базы данных. Двадцать пять процентов — это уже не экзотика! Так что, актуальность, думаю, можно считать доказанной.
------
*Ссылку на объект я тоже обозвал примитивным типом, поскольку это всего лишь число, вся мудрость и навороченность которой проявляется только после "пролезания" по ней (операция разыменования). Понимаю, что это утверждение грубо противоречит КОП, но речь сейчас не об этом, т.к. в контексте разговора про не-объекты ссылка на объекты интереса не представляет.
------
Главная технологическая проблема не-объектов заключается в том, что их характеристики не принадлежат им эксклюзивно. То есть поле Currency не-объекта Employee.Salary также принадлежит не-объекту Employee.Balance и, конечно же, объекту Employee. И если мы делаем перехватчик события, изменяющего Employee.Salary.Currency, то оно должно вызываться также и при изменении Employee.Balance.Currency! Реально ведь поле одно и то же! То есть мало того, что нам не очень понятно, как нам хранить ссылки на не-объекты, но и введение в обращение не-объектов может вызвать изменение вычислительной модели. В плане придания ей свойств транзакционности.
Пример:
emp.Balance.Currency = Currency("RUR");
Что при этом должно произойти?
Должен быть вызван код, срабатывающий при установке свойства Currency объекта Balance
Должен быть вызван код, срабатывающий при установке свойства Currency объекта Employee (например, должен быть вздёрнут флаг модифицированности)
Должен быть вызван код, срабатывающий при установке свойства Currency объекта Salary
Вопрос: в какой последовательности? Ответ: в любой. Т.е. ХЗ в какой.
Ещё вопрос: если произойдёт облом в коде, обрабатывающем Salary.Currency, то все изменения должны откатиться. В том числе, флаг модифицированности объекта emp должен вернуться в прежнее положение.
Всё же, всё же... Даже не смотря на то, что появление не-объектов поднимает эти вопросы, думаю, игра стоит свечь. Просто в силу актуальности (см. выше).
S>А умные указатели имеют целый список проблем (за полноту не ручаюсь):
Не надо меня агитировать против smart pointers. Лично для меня достаточно вот этого:
S> Этот механизм опирается на специфику С++ и шаблоны, что существенно ограничивает его использование. Но даже в С++ они используются в весьма ограниченных целях для совершенно конкретных задач.
Так как в своей практике я использую C++ весьма эпизодически, вопрос использования этого чуда отпадает сам собой.
Здравствуйте, exp_1, Вы писали:
_>Я сейчас приведу несколько тривиальных утверждений, которые мог бы написать несколько лет назад, без всякого отношения к теме, но которые мне кажутся здесь весьма уместными.
_>Кратко, как я понял (спроецировал на понятное мне) про КОП:
_>Есть объекты, и есть ссылки на них и есть пространства их жизни. На один объект возможны разные ссылки, реализующие разные его представления и разное поведение, которые валидны в разных (каждая в своём), возможно пересекающихся слоях и контекстах.
Я бы добавил, что объекты не могут существовать без ссылок (нет ссылки — нет объекта), а вот ссылки могут существовать без объекта. В частности, можно создать сложную программу вообще без объектов, а манипулирующую только ссылками. Другая крайность, это когда все функции сосредоточены в объектах, а ссылки примитивны (это ООП).
Одна проблема формализации идеи об объектах и ссылках в том, что объект может (и всегда имеет) множество ссылок. Например, запись в БД имеет положение на диске, физический адрес в памяти, первичный ключ и м.б. еще что-то, выдуманное программистом для ее идентификации. Компьютер имеет имя, IP-адрес, MAC-адрес и м.б. еще что-то выдуманное программистом для данной системы. В КОП предлагается конкретные средства, как работать с такой системой адресации объектов.
_>Естественно, теоретически, всё можно реализовать имеющимися средствами, но:
_>Результатом новой парадигмы может оказаться появление практической возможности для создания программных решений действительно сложных и объёмных проблем человеком, или коллективом людей. Это весьма достойная цель, и очевидно, что преимущества метода, ещё довольно сырого, предназначенного для серьёзных проектов — весьма не просто (на мой взгляд, так элементарно, но мне лень ) продемонстрировать на простых примерах.
_>Сейчас такие задачи, которые не решаются из-за своей сложности (многоплановости) и ограниченности имеющихся интеллектуальных и временных ресурсов встают всё чаще и повсеместнее.
Здесь уместно вспомнить про термин глобализация, который применяется к социальным аспектам жизни, но редко к архитектуре систем. Например, мы пишем простое веб-приложение. Но оно покрывает огромное жизненное пространство объектов. Так, интерфейс пишется на PHP и JavaScript, которые взаимодействуют с сервером приложения, который берет данные из БД, а также др. систем как платежные системы. Так в чем же проблема таких глобальных систем? Предположение: проблемы возникают на стыке пространств, где собственно концентрируется большая часть функций. В КОП это предположение формулируется в виде исходного принципа (неформального конечно, но весьма важно для всего дальнейшего развития). А далее формально описывается что такое пространство, что такое граница, что такое объекты, ссылки и др. элементы. Но главное, это как все это вместе работает.
_>Подчеркну, что речь не идёт об ускорении и упрощении для разработки и поддержки кода. Речь не идёт о качестве, переносимости и масштабируемости кода. Речь идёт о создании возможности, которой сейчас не существует вовсе, как например практически не существует возможности для написания современной RPG на ассемблере, по сравнению с каким-нибудь скриптовым языком для специального движка.
В долгосрочной перспективе конечно простота и эффективность будут играть первостепенную роль. Но на начальном этапе оценивать их было бы преждевременно, поскольку не все для этого готово. Сперва надо (во многом интуитивно) прикинуть, а является ли этот подход просто жизнеспособным. Существует много дизайн-альтернатив для дальнейшего развития и тем более для реализации, так что до зрелости еще очень и очень далеко.
Здравствуйте, Voblin, Вы писали:
V>Например, у меня вот это родилось из размышлений о том, почему в серьёзных бизнес-системах (всякое там ERP, CRM, бухгалтерия, склад и т.д.) полноценный ОО-подход при проектировании бизнес-логики не применяется.
Выглядит очень похоже на множественную динамическую классификацию, которая описывается в UML. Правда, ни одной реализации этой идеи на практике я пока не встречал. Ты не видел чего-нибудь еще на эту тему?
Здравствуйте, Дарней, Вы писали:
Д>Выглядит очень похоже на множественную динамическую классификацию, которая описывается в UML. Правда, ни одной реализации этой идеи на практике я пока не встречал. Ты не видел чего-нибудь еще на эту тему?
Где-то проскакивало, что в Haskell есть что-то на эту тему, но моё изучение этого зверя до темы тамошней типизации не дошло
Здравствуйте, Voblin, Вы писали:
V>Всё же, всё же... Даже не смотря на то, что появление не-объектов поднимает эти вопросы, думаю, игра стоит свечь. Просто в силу актуальности (см. выше).
А почему нельзя просто определить геттеры и сеттеры, которые бы собственно учитывали специфику поведения не-объектов?
Если же эту логику надо отделить от класса (поскольку она применяется во многих классах), то можно применить АОП. В этом случае в аспекте указывается, что при доступе к нужным полям нужных классов будет отрабатываться какая-то дополнительная логика.
Впрочем, интуитивно, я понимаю, что это не то, что нужно... Основная проблема состоит в том, что не-объекту для правильного поведения необходимо выйти за свои пределы в контекст содержащего его объекта (например, для доступа к полю единицы измерения, которое необходимо для правильной интерпретации числа). В этом случае, помещая не-объект в разные объекты, мы можем получить разное поведение. Хм, интересная идея, поскольку мы приходим к понятию контекста объекта (как двойственному к понятию контекста контейнера). В КОП развито понятие контекста контейнера, т.е. объект живет в контейнере, который является его контекстом и может влиять на поведение. А здесь мы приходим к механизму контекста, в котором могут жить поля (не-объекты в общем случае). Сразу можно предложить использование аналогичного механизма, а именно, ключевого слова objectContext, которое применяется к не-объекту и позволяет получить объект, в котором он находится. Например, salary.objectContext.currency даст валюту. Получаем контекстно зависимое поведение аналогичное зависимости от среды или контейнера. Интересная идея, надо будет подумать, как это можно развить дальше...
S>>А умные указатели имеют целый список проблем (за полноту не ручаюсь): V>Не надо меня агитировать против smart pointers. Лично для меня достаточно вот этого: V>
S>> Этот механизм опирается на специфику С++ и шаблоны, что существенно ограничивает его использование. Но даже в С++ они используются в весьма ограниченных целях для совершенно конкретных задач. V>V>Так как в своей практике я использую C++ весьма эпизодически, вопрос использования этого чуда отпадает сам собой.
Несмотря на специфичность и ограниченность механизма умных указателей, мотивация, которая за ними стоит, имеет весьма высокую общность. Я бы сказал, что аргументы в пользу необходимости умных ссылок могут быть на 90% применены к КОП. Т.е. проще говоря, чтобы понять для чего нужен КОП, можно начать чтение с умных ссылок. (Преимущество в том, что там эта сказка уже гладко изложена, а в КОП есть только фрагменты.)
Здравствуйте, savinov, Вы писали:
V>>Всё же, всё же... Даже не смотря на то, что появление не-объектов поднимает эти вопросы, думаю, игра стоит свечь. Просто в силу актуальности (см. выше).
S>А почему нельзя просто определить геттеры и сеттеры, которые бы собственно учитывали специфику поведения не-объектов?
Просто потому, что к одному значению (в частности, Currency) у нас присасывается несколько сеттеров ( ), которые во-первых, ничего не знают друг о друге, а, во-вторых, могут между собой законфликтовать.
S>Если же эту логику надо отделить от класса (поскольку она применяется во многих классах), то можно применить АОП. В этом случае в аспекте указывается, что при доступе к нужным полям нужных классов будет отрабатываться какая-то дополнительная логика.
АОП мне в принципе не нравится. В самой концепции АОПа есть очень хитро спрятанный логический баг.
S>Впрочем, интуитивно, я понимаю, что это не то, что нужно... Основная проблема состоит в том, что не-объекту для правильного поведения необходимо выйти за свои пределы в контекст содержащего его объекта...
А вот и нет! Не-объектный класс Money не должен лазить в своего хозяина (Employee, OrderDetails и т.д.). Его область деятельности ограничивается его полями (вернее, не-только-его полями) Value и Currency.
А о своём контексте он ничего не знает. Что называется, куда воткнули, там и сидит. То есть нельзя сказать, что S>... salary.objectContext.currency даст валюту.
Класс Money, которому принадлежит Salary, не в курсе, что у его "контекста" есть поле Currency. Например, для orderdetails.Price валюта может сидеть в objectContext.Order.Customer.Country.Currency (о как всё запущено!).
Здравствуйте, savinov, Вы писали:
S>У меня такое ощущение, что я общаюсь с новым русским. И по форме и по содержанию.
И очень зря. У нас же не институт благородных девиц, а форум профессионалов. И Андрей разбирается в предмете очень и очень хорошо. Ты же, когда публиковался в форуме, хотел получить обратную связь от квалифицированных коллег? Ну вот и получаешь. И по форме и по содержанию AVK очень точно ставит вопрос. А ты вместо того, чтобы подумать, начинаешь кипятиться и возмущаться.
S>Стучать по столу и требовать ты у заказчика можешь, когда заплатишь, а здесь ты можешь вежливо попросить что-то втолковать, если не можешь разобраться самостоятельно.
Пока что у меня (и не только) есть подозрение, что это как раз ты не можешь разобраться самостоятельно. AVK>>а) Скорости написания кода AVK>>б) Сложности поддержки кода AVK>>в) Читаемости кода[/q]
S>Ты хоть примерно представляешь, как может быть оформлен ответ на твои вопросы?
Естественно, может. И я могу. S>Если нет, я подскажу: это может занять 10 лет и тома текстов (книги, статьи и т.п.)
Да ничего подобного. Если ты сам понимаешь, какие у твоей идеи преимущества, то тебе не составит труда изложить их в двух-трех абзацах. Вот, к примеру, вся суть квантовой механики укладывается в главу "введение" третьего тома Ландау-Лифшица.
S>Это термины, которые "специфичны" для любого подхода,
Совершенно верно. А ты что, полагаешь, что твой подход какой-то особенный, и к нему нельзя подходить с тем же аршином, что и, к примеру, к функциональному программированию? S>причем не только в программировании.
Серьехно? Ну-ка, расскажи мне, для каких областей, кроме программирования, специфичен термин "сложность поддержки кода". Мне очень интересно расширить свой кругозор. S>Так что видимо у тебя есть серьезные проблемы с пониманием, что есть специфичное и что есть общее.
Пока что мое понимание совпадает с пониманием Андрея. А вот твое понимание вызывает у меня обоснованные сомнения. AVK>>Это вопрос, даже не сомневайся. Народ тут с нетерпением ждет на него ответа. S>Говори, пожалуйста, от себя.
Ждет-ждет. Не сомневайся.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, savinov, Вы писали:
C>>Тогда это называется "графоманство".
S>Ну хорошо, я не против. Называйте это как хотите, мне это безразлично, и я меньше всего об этом думаю.
S>В общем, все свелось к обсуждению как это называется и не преследует ли автор каких-то корыстных целей.
Да нет же, прямо наоборот — это читатели преследуют корыстные цели — они хотят найти как это можно применить на практике.
Здравствуйте, savinov, Вы писали:
S>Это все равно, что сравнивать принципы архитектуры с лопатой. Я буду говорить, как надо строить дом, а ты будешь говорить, что все это можно и лопатой сделать. Причем самое интересное, что ты будешь прав, но я к этому мог бы добавить, что кроме лопаты есть еще экскаватор, отбойный молоток и др. средства. Но все это не имеет отношения к предмету разговора.
Некорректная аналогия.
Правильная будет такая: ты предлагаешь для строительных работ создать биоробота, у которого вместо рук — лопаты, чотбы копать землю. Поскольку одних лопат мало, этот боробот будет поддерживать возможность трансворирования конечностей в экскаваторные ковши, отбойные молотки, метлы и "все прочее". На это тебе возражают, что в этом мало смысла — проще взять обычного человека и набор инструментов, которыми он сможет воспользоваться. Ты же отвечаешь "ну вот, вы ничего не понимаете в биороботах, а предлагаете использовать сменные инструменты. Ваша проблема в том, что за 40000 лет все привыкли к использованию инструментов и не могут понять идею биоробота."
), которые во-первых, ничего не знают друг о друге, а, во-вторых, могут между собой законфликтовать.
1.1.4 stable rev. 510
