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

L>>> Все верно. Имеются общеивестные критерии ООП: инкапсуляция,
L>>> полиморфизм, наследование. Из этих критериев, в частности,
L>>> следует, что "объекты с состоянием, обменивающиеся сообщениями". И
L>>> в этом смысле ООП он и в Африке ООП: языки, которые не
L>>> поддерживают его концепции не являются ОО-языками.

YК>>Уже не раз говорилось о том, что наследование — не обязательный признак ОО-языка.
YК>>Наследование, в частности — это способ обеспечить полиморфизм в статически типизированных языках. При наличии динамической типизации без наследования можно обойтись.


LP>Все же критерии ООП именно такие: полиморфизм, инкапсуляция, наследование. Это не я сказал. Если выкинуть отсюда что-либо, быть может это и будет ООП в ВАШЕМ понимании, но это не будет ООП в соответствии с его определением.

Вам же конечно не составит труда привести определение ООП, а также автора этого определения?

Здравствуйте, Sergey J. A., Вы писали:
SJA>Но на уровне рантайма модификации то могут быть ?
Прежде, чем переходить на уровень рантайма, неплохо определиться с семантикой языковых конструкций.
SJA> Вот пусть компилятор транслирует "указатель на объект" в программе на указатель на указатель на функцию в реальном коде.
SJA>А применнеие ф-ии к объекту транслирует в добавление ф-ии в этот список. При этом меняется только указатель на ф-ию.
Ничего не получится.

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

LP>>Все же критерии ООП именно такие: полиморфизм, инкапсуляция, наследование. Это не я сказал. Если выкинуть отсюда что-либо, быть может это и будет ООП в ВАШЕМ понимании, но это не будет ООП в соответствии с его определением.

YК>Вам же конечно не составит труда привести определение ООП, а также автора этого определения?

У ООП нет однозначного определения.

Минимум для объектной ориентации, это
— есть объекты
— объекты шлют друг другу сообщения, где аргументами и ответами являются ссылки на другие объекты

Этого как ни странно, достаточно. Здесь нет ни полиморфизма, ни наследования (это понятия ОО-системы типов, которой может не быть); инкапсуляция следует сама собой из того, что нет других способов доступа кроме сообщений. Тут нет классов (интерфейсов) — объектам не обязательно знать, на какие сообщения какого формата другой объект умеет реагировать! Неверное сообщение может просто давать runtime error. И некоторые ОО-системы успешно работают подобным образом.

Конечно, такие логические структуры можно реализовать на любом процедурном, функциональном языке, и даже на ассемблере, и потом программировать в стиле ОО, но никто не называет ассемблер ОО-языком или языком, поддерживающим ООП Чтобы так называться, надо иметь синтаксическую поддержку — для посылки сообщений, для реализации объектов, для системы типов.

Так что даже если вы реализуете этот минимум в некотором ФП, это не покажет наличие поддержки ОО в этом ФП.

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

SJA>> Вот пусть компилятор транслирует "указатель на объект" в программе на указатель на указатель на функцию в реальном коде.
SJA>>А применнеие ф-ии к объекту транслирует в добавление ф-ии в этот список. При этом меняется только указатель на ф-ию.
S>Ничего не получится.
Не вижу пока никаких проблем.

//////////// Runtime ///////////////
typedef std::string (*string_converter)(std::string);

class string_converter_node
{
public:
    string_converter_node(string_converter f)
    {
        converter = f;
        next = NULL;
    }
    string_converter converter;
    string_converter_node * next;
};

void modify_string(string_converter_node *root, string_converter f)
{
    while(root->next != NULL)
        root = root->next;
    
    root->next = new string_converter_node(f);
}

std::string get_str(string_converter_node *root)
{
    std::string cur;

    while(root != NULL)
    {
        cur = root->converter(cur);
        root = root->next;
    }

    return cur;
}


/////////////// Код приложения ///////////////////////////////
concat s1 s2 = s1 + s2

s1 = "foo"
s2 = s1
s1.concat("bar")
print s1
print s2

/////////////////////////// Транслируется в ////////////////////////

// constant "foo"
std::string foo(std::string)
{
    return "foo";
}

// constant "bar"
std::string bar(std::string)
{
    return "bar";
}

std::string concat(std::string s1, std::string s2)
{
    return s1 + s2;
}

void main()
{
    string_converter_node *s1 = new string_converter_node(foo);
    string_converter_node *s2 = s1;
    modify_string(s, lambda x: concat(x, bar));    // нужна поддержка карринга
    puts(get_str(s1).c_str());
    puts(get_str(s2).c_str());
}

Здравствуйте, Sergey J. A., Вы писали:

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

SJA>>> Вот пусть компилятор транслирует "указатель на объект" в программе на указатель на указатель на функцию в реальном коде.
SJA>>>А применнеие ф-ии к объекту транслирует в добавление ф-ии в этот список. При этом меняется только указатель на ф-ию.
S>>Ничего не получится.
SJA>Не вижу пока никаких проблем.
Указатель в ФП модифицировать нельзя. Поэтому "указатель на указатель" ничего интересного тебе не даст. Всё, на этом приехали. Максимум, что можно получить — функцию "Iterate", которая получит по текущему состоянию "мира" новое состояние "мира", создав клоны всех-всех объектов так, чтобы все ссылки проапдейтились. С реалистической точки зрения — малоинтересно.

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

SJA>>>> Вот пусть компилятор транслирует "указатель на объект" в программе на указатель на указатель на функцию в реальном коде.
SJA>>>>А применнеие ф-ии к объекту транслирует в добавление ф-ии в этот список. При этом меняется только указатель на ф-ию.
S>>>Ничего не получится.
SJA>>Не вижу пока никаких проблем.
S>Указатель в ФП модифицировать нельзя. Поэтому "указатель на указатель" ничего интересного тебе не даст. Всё, на этом приехали.

На уровне языка никаких указателей на указатели нет:

/////////////// Код приложения ///////////////////////////////
concat s1 s2 = s1 + s2

s1 = "foo"
s2 = s1
s1.concat("bar")
print s1
print s2

Есть 2 ссылки на объекты — s1, s2. Через s1 объект модифицируется. Через s2 можно наблюдать эту модификацию. С точки зрения прикладного програмиста, вообще не видно как реализовано состояние объектов.

Здравствуйте, Sergey J. A., Вы писали:

SJA>

SJA>/////////////// Код приложения ///////////////////////////////
SJA>concat s1 s2 = s1 + s2

SJA>s1 = "foo"
SJA>s2 = s1
SJA>s1.concat("bar")
SJA>print s1
SJA>print s2
SJA>

SJA>Есть 2 ссылки на объекты — s1, s2. Через s1 объект модифицируется. Через s2 можно наблюдать эту модификацию. С точки зрения прикладного програмиста, вообще не видно как реализовано состояние объектов.

Ну и? Это получился некий императивный язык. Тут нельзя переставить местами 3 и 4 строки — декларативность нарушена.

Hello, !
You wrote on Mon, 09 Jul 2007 04:26:10 GMT:

LP>>> Все же критерии ООП именно такие: полиморфизм, инкапсуляция,
LP>>> наследование. Это не я сказал. Если выкинуть отсюда что-либо,
LP>>> быть может это и будет ООП в ВАШЕМ понимании, но это не будет
LP>>> ООП в соответствии с его определением.

YК>> Вам же конечно не составит труда привести определение ООП, а
YК>> также автора этого определения?

К> У ООП нет однозначного определения.

К> Минимум для объектной ориентации, это — есть объекты — объекты
К> шлют друг другу сообщения, где аргументами и ответами являются
К> ссылки на другие объекты

О чем и речь

Здравствуйте, Sergey J. A., Вы писали:
SJA>На уровне языка никаких указателей на указатели нет:
SJA>

SJA>/////////////// Код приложения ///////////////////////////////
SJA>concat s1 s2 = s1 + s2

SJA>s1 = "foo"
SJA>s2 = s1
SJA>s1.concat("bar")
SJA>print s1
SJA>print s2
SJA>

SJA>Есть 2 ссылки на объекты — s1, s2. Через s1 объект модифицируется.
Еще раз: это невозможно в ФП. Вся фишка в том, что s1.concat не может ничего поменять. Всё, что можно сделать — это ввести новое определение для s1: s1 = s1.concat("bar").
SJA>Через s2 можно наблюдать эту модификацию.
Нет, нельзя. s2 является псевдонимом для "старого" s1, который был до дописывания "bar".

SJA>С точки зрения прикладного програмиста, вообще не видно как реализовано состояние объектов.
Это работает только в императивном языке.

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

SJA>>Есть 2 ссылки на объекты — s1, s2. Через s1 объект модифицируется. Через s2 можно наблюдать эту модификацию. С точки зрения прикладного програмиста, вообще не видно как реализовано состояние объектов.

D>Ну и? Это получился некий императивный язык. Тут нельзя переставить местами 3 и 4 строки — декларативность нарушена.

Вообще-то я и не собирался показать декларативный язык. Отвечал на

Строго говоря, так и есть. Объект только тогда является объектом, когда у него есть СОСТОЯНИЕ, а состояние не может быть не изменяемым. Такой "объект" может быть с легкостью заменен на функцию, возвращающей значение.

Я наверное не догнал, что это про объекты именно в дкларативных языках ?

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

Собственно видимо я затупил изначально

Автор: Sergey J. A.
Дата: 09.07.07