таки уже не самый самый. Советую посмотреть на Eiffel. Автор языка намного интересней и проще прививает любовь к своему детищу, чем это получается у ТС
Это можно назвать решением, но назвать его простым не могу. Это надо класс надо редактировать. И все заново транслировать. А в моем случае класс может находится в библиотеке и не обязательно его вообще трогать. Все необходимые операции можно выполнить при создании объекта. Причем свойства это частный случай. Более естественным будет случай когда объект имеет собственные события. Не все имеет смысл предусматривать в классе, а иногда это просто не возможно.а в чем заключается неразрешимость? К примеру на C/C#/Java добавляем внутри класса коллекцию для хранения свойств и после инстанцирования добавляем, удаляем нужные/ненужные свойства. При этом получаем описанную вами ситуацию - класс не содержит описания специфичных свойств, но их можно добавить объекту после инстанцирования. Так в чем-же тут заключается суть неразрешимости?
Это тоже самое что создавать класс для каждого объекта. А смысл?а что мешает создать абстрактный класс бабочки, а специфические свойства и методы определить в наследниках?
С интерфейсами и прочими радостями см. раздел 4. Реализация. Наследование. Интерфейсы. Прецеденты. Роли. Стили. Модели. Сценарии.
Хороший вопрос. Долго придумывал. Но, придумал. Получилось естественно. Это касается работы виртуальной машины. Она выполняет свойства объекта (инструкции тоже объекты), а затем вложеные объекты. Вложеные объекты можно добавить к любому объекту в группе (обычно фигурные скобки) сразу за определением объекта. См. общий синтаксис определения объекта. Так при приеме свойств объекта определеных в классе (а именно они составляют то, что подлежит передаче) идет проверка на наличие вложеных объектов в принимаемый объект. Если там что-то есть, это тоже необходимо принять.
На вашем примере с насекомыми, допустим вы хотите передать объект описывающий пингвина, который относится к классу птиц. Передали вы описание класса птицы на приемную сторону, но как вы собираетесь передавать информацию о наличии свойства "неумение летать", которое у объекта присутствует, но в классе птицы описано не было?
каждый язык имеет свои особенности, чтобы хорошо использовать язык не достаточно изучить его синтаксис, кроме этого нужно изучить как принято реализовывать те или инные сущности, какие есть подводные камни, как их принято обходить в этом языке. У разных языков есть много общего, но есть и особенности, для которых нет аналогов в родственных языках. Изучение всех этих тонкостей и занимает основное время, сам синтаксис как правило можно изучить достаточно быстро (порой за пару часов), а вот на изучение всего остального уходит основная масса времени
Но, она работает. А насчет плюсов я так понял с нейронными сетями вы знакомы. Значит интересуетесь. Обратите внимание на логические и функциональные языки и их возможности. И почуствуйте разницу. Хотя бы это. Поверьте будет интересно.
Можно ничего не делать, а можно и делать. Я предпочитаю делать. И опять про XML. Вы посты читаете? Про рекомендованые файлы уже молчу. XML и TLL принципиально разные вещи. Эту разницу я уже объяснял.
Каждому свое. Предпочитаешь не парить, не парь. Я предложил свой вариант. Будем обсуждать студию 2010 или таки систему LADA?
У меня впечатление такое, что после редактирования класса его таки прийдется оттранслировать. Но, дело не в том, что можно изменить класс, а в том, что этого можно не делать, если оно того не стоит. Вот приведу пример привязки события (кстати, события у меня здорово отличаются от общепринятых) переменной Integer. Изменять ради этого класс Integer сори.. не разумно.ничего сложного в том чтобы добавить в описание класса одну строчку, добавляющую коллекцию (хранения свойств или обработчиков событий), не вижу
Заново транслировать не нужно - класс транслируется один раз, после этого его описание находится в библиотеке и необязательно его вообще трогать. Все необходимые операции можно выполнить при создании объекта - создаем новый объект класса из библиотеки, добавляем и добавляем в него нужные свойства и обработчики событий...
Повторюсь. А можно и не создавать классы. По поводу где брать код, это уже в глубину полезем. Понятно, что этот вопрос продуман. Частично, я это рассказывал описывая алгоритм приема-передачи.собственно создавать классы для каждого объекта можно в рантайме, и спокойно работать с ними - с помощью рефлексии. Писать классы в редакторе для этого не нужно, программа сама напишет нужный класс и инстанцирует его, с этим проблем в C# например нет. Возникает неудобство с написанием кода, работающим с такими динамическими классами - код получается громоздким и тяжело читаемым, но это тоже решается добавлением поддержки dynamic typing в синтаксис языка. В последних версиях C# это поддерживается.
Другое дело что непонятно - где вы собираетесь брать код методов в рантайме для новых объектов, если на этапе компиляции этот код не был задан и не было известно как его задать?
class MyParser
{
private Integer m_len;
private Integer m_ind;
public MyParser()
{
m_ind = new Integer(0);
m_len = new Integer(0);
m_ind.Change += m_ind_ChangeHandler; // подписка на событие Change
}
private m_ind_ChangeHandler(Integer oldValue)
{
if(m_ind >= m_len)
{
// обрабатываем выход индекса за пределы допустимых значений
}
}
}Для особо одаренных повторюсь. В системе LADA нет самой необходимости редактировать класс. Добавляются новые свойства, методы и события непосредственно к объекту. Разницу уловите. Ну, уже не первый раз пишу!!!Один раз класс действительно прийдется скомпилировать - после того как он написан, или вы предлагаете использовать класс, код которого ни разу не компилировался?
Где я писал о необходимости изменять класс? Я ж пятый раз вам пишу о том, что такой необходимости нет. И над чем смеемся?подписываться на изменение переменной типа integer - оригинальное решение
Однако я не пойму зачем для этого изменять класс Integer?
Ехидное замечание про модификацию класса Integer пропустим. Думаю с пятого раза должно дойти что это и не предлагается. Вы считаете ваш пример без хитростей? А парсер? Ну, хотя бы количество строк посчитайте для сравнения. Но, это еще мелочи. Есть два серьезных замечания.В классическом языке с общепринятной объектной моделью, подписка происходит без необходимости модификации класса
Например:
Код:class MyParser { private Integer m_len; private Integer m_ind; public MyParser() { m_ind = new Integer(0); m_len = new Integer(0); m_ind.Change += m_ind_ChangeHandler; // подписка на событие Change } private m_ind_ChangeHandler(Integer oldValue) { if(m_ind >= m_len) { // обрабатываем выход индекса за пределы допустимых значений } } }
как видим используя существующие языки, без каких-либо хитростей можно подписаться на событие класса Integer, при этом модифицировать класс Integer нет никакой надобности
Как говорится "мы простых путей не ищем" 
. Почему Я должен буду использовать вашу LADA?
Одной из проблем ООП, является как раз невозможность изменять реализацию (это мой термин) объекта. Строгое соответствие -класс-объект заставляет плодить и усложнять классы даже если по большому счету необходимости в этом нет. Как это сказывается на эффективности при выполнении поймет каждый.
Здесь слишком много вопросов. Надо бы разделить. Я так не пойму на что отвечать.
А что под этим понимается? Написание в тексте? Или как оно выполняется? Или это про полиморфизм? Это разные вещи. Да и не молюсь я на ОО. И вам не советую. В чистом виде мою систему нельзя назвать ОО. При обсуждении было решено, что это скорее формы (есть еще такое понятие) я и с этим не согласен.. Все-таки ближе к ОО. Но это теоритезирование. Оно вам надо? Вот что предложил, то и предложил. Но смотрю, тут гении пару строк прочитают, чего-то от себя придумают, и мазохируют на свою придумку. Господа, читайте.. Иначе обсуждения не получается.
Знаком. Пока не вижу ничего плохого в том, что присутствуют знакомые концепции. Это ж затравка. Для начала достаточно, а дальше посмотрим.
Так что бы обзор, так не проводил. Но, определенная работа, конечно, же проведена. Вот сейчас просмотрю то, что вы советуете. Спасибо за ссылку. Пару дней мне для анализа.
Это не я сравниваю. Вопросы задают, надо ж отвечать. Вот все спрашивают про новое и никто пока не обратил внимания что там две разные по смыслу операции присваивания. Это важно что б почуствовать разницу. И, не все сразу. Понемногу будет понятна разница и в другом. Например, в таких понятиях как группирование и реализация. Вы первый обратили внимание на возможности фунциональной парадигмы. Пока все рвут на части классы и объекты
Согласен. Трудно придумывать примеры. Но, я стараюсь. Опять же. Не все сразу. Думаю данное обсуждение поможет мне и примеры придумывать.