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

S>Тогда никакой чуши — посылаем объекту 7 сообщение "прибавь объект 3", он возвращает нам объект 10.

S>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?

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

VD>В языках где модули действительно используются по назначению (например, OCaml) АТД представляются именно модулями. В них модуль — это первоклассниц сущность.

Модуль да, зато в объектах OCaml (http://www.ocaml.spb.ru/chapter03.html#id2259433) тоже как и в дельфи очень самостийный private
Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.
Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

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

A>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов.
Это полная чушь. Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.

A>Наследования интерфейсов нет.

intarface IA {}
intarface IB:IA {}

A>Не путайте твердое с мягким.
Ты полную чушь говоришь.

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


VD>Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.

От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:

#include <iostream>
#include <memory>

using namespace std;

class Base
{
public:
    virtual ~Base()
    {
    }
    
    void Proccess()
    {
    DoProccess();
    }
    
private:
    virtual void DoProccess()
    {
    cout << "Base" << endl;
    }
};


class Derive : public Base
{
private:
    virtual void DoProccess()
    {
    cout << "Derive" << endl;
    }
};


int main()
{
auto_ptr<Base> a(new Base);
a->Proccess();

a.reset(new Derive);
a->Proccess();
}

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

A>Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода.

Наверное стоит начать отсюда

Или отсюда

Автор: Gaperton
Дата: 26.02.08

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

S>Здравствуйте, samius, Вы писали:
S>>Да, и в нем не было слова private, были только секции interface/implementation, некие аналоги h,c файлов.
S>Вы лучше такие аналогии не применяйте. ...
S>Паскаль, в отличие от С, имел нормальную модульную архитектуру. С поддержкой, естественно, метаданных.
Это ход в сторону. private таки не было в паскале.

S>>О том что другие люди таки посчитали что область видимости private слишком широка.
S>Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи.
На момент введения strict никакое новое поколение не создавалось. Ввели его если не ошибаюсь, в Delphi 7. Сам не щупал, но где-то в инете видел. Да и интеграцией с дотнетом тогда не пахло.

S>>Я отвечал на это
S>>

S>>К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.

S>>В том плане что несколько классов можно определить в одном header-е. Аналогия не полная, но границы доступа определять позволяет.
S>Аналогия вообще никакая. То, что несколько классов случайно оказались в одном хидере, это даже не часть языка. Нет никакого способа сказать, какой класс пришёл из какого хидера — как только я написал список инклюдов, начинается свальный грех.
S>Именно поэтому нет никакого ключевого слова вроде "header internal", которое бы позволило дать доступ к мемберу классам из "того же хидера".
Я писал лишь о границе доступа на уровне классов. Никаких "header internal" не подразумевал.

S>>разве в оригинальном паскале было слово private?
S>В TP 5.0 — было. Хейльсберг поставил перед собой задачу сделать язык, пригодный для изучения ООП. Он гордился тем, что добился этого всего четырьмя ключевыми словами. То, что вы предлагаете, означало как минимум на 20% больше новых ключевых слов.
Я ничего не предлагаю. Я говорю что это нехарактерно для ООП.
Кстати, ОО было в TP 5.5. А до него private не было (почти уверен).

S>(Вздыхает). То, что вы называете "oбычно" — продукт совсем другой эпохи. В 1989 никаких "обычно" ещё не было. В том же году в С++ добавили access modifier protected. В Simula никаких private не было.
Было, в Simula 87, и ранее в TOPS-10. До тех пор в Simula был hidden.

S>А в наши дни, конечно же, использовать Delphi для примеров в статьях не про Delphi — неожиданно. Тем более при рассуждении о типизации — дельфийская система типов изобилует причудливыми странностями ничуть не меньше, чем древнеэльфийский у JRRT.
+1

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

G>Ты полную чушь говоришь.

Похоже он имеет в виду это:

unit Foo;

interace 

{ вот эту секцию }

implementation


initialization


finalization

end;

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


S>>Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи.
S>На момент введения strict никакое новое поколение не создавалось. Ввели его если не ошибаюсь, в Delphi 7. Сам не щупал, но где-то в инете видел. Да и интеграцией с дотнетом тогда не пахло.

strict private (вместе с перегрузкой операторов, sealed, вложенными типами и прочим) ввели в Delphi 2007 именно в связи с поддержкой .NET-а.

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

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


S>>>Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи.
S>>На момент введения strict никакое новое поколение не создавалось. Ввели его если не ошибаюсь, в Delphi 7. Сам не щупал, но где-то в инете видел. Да и интеграцией с дотнетом тогда не пахло.

H>strict private (вместе с перегрузкой операторов, sealed, вложенными типами и прочим) ввели в Delphi 2007 именно в связи с поддержкой .NET-а.
Да, я неверно истолковал информацию

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

h> strict private (вместе с перегрузкой операторов, sealed, вложенными типами и прочим) ввели в Delphi 2007 именно в связи с поддержкой .NET-а.

Вообще-то в 2005

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

FR>Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.

Ну, да если private самом деле protected, то на самом деле обсуждать тут нечего, кроме (разве что) фееричного мышления авторов языка.

Видимо по этому в ОКамле и используют модули вместо классов.

FR>Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

Я правильно понимаю, что в ОКамле тип — это что-то вроде интерфейса?

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

FR>>Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.

VD>Ну, да если private самом деле protected, то на самом деле обсуждать тут нечего, кроме (разве что) фееричного мышления авторов языка.

Тык французы

VD>Видимо по этому в ОКамле и используют модули вместо классов.

Ну я бы не сказал. ОО система там вполне неплохая, хоть и своеобразная.

FR>>Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

VD>Я правильно понимаю, что в ОКамле тип — это что-то вроде интерфейса?

Там структурная типизация притом она применятся непосредственно
к объектам, а класс практически чистый сахар ну и для наследования, ну и интерфейсы для структурной типизации также становятся не
нужными.

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

FR>Там структурная типизация притом она применятся непосредственно к объектам, а класс практически чистый сахар ну и для наследования, ну и интерфейсы для структурной типизации также становятся не нужными.

Ну, да. Туплю. Слишкмо привык к номинальной системе типов. Как грится когда в руках молоток, все вокруг кажется гвоздем.

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

S>Нужно понимать, что Delphi вырос из Паскаля, в котором границы областей видимости были чётко связаны с unit задолго до вкорячивания в него OOP.
S>Именно опыт с Delphi и прочими языками привёл в конечном итоге к обобщённой модели access modifiers, принятой в дотНет.

Я может бы плохо помню Паскаль тех времен, но я упорно не могу припомнить в нем никаких модификаторов доступа. В Паскале была секция interface где описывались публикуемые функции и переменный. А вот никаких модификаторов доступа я припомнить (до появления ОбжектПаскаля) не могу.

Так что или нужно ткнуть меня носом в описание модификаторов доступа в до ОбжектПаскалевскую эру, или отбросить твою аргументацию как не верную.

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

S>>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

A>В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?

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

Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.

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

S>К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.

+1 И перегрузки тоже нет, а полиморфизм на лицо.

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

H>Похоже он имеет в виду это:
H>

H>unit Foo;
H>interace 

H>{ вот эту секцию }

H>implementation
H>initialization
H>finalization
H>end;
H>

Вроде нет, так как рядом он говорил о списке методов и включении методов (при наследовании интерфейсов).

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

VD>Так что или нужно ткнуть меня носом в описание модификаторов доступа в до ОбжектПаскалевскую эру, или отбросить твою аргументацию как не верную.
Добавлены в TP 5.5, в 1989 году, вместе с ключевыми словами object и virtual.

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

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

A>>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов.
G>Это полная чушь. Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.

A>>Наследования интерфейсов нет.

G>

G>intarface IA {}
G>intarface IB:IA {}
G>

A>>Не путайте твердое с мягким.
G>Ты полную чушь говоришь.

Вы смешали как раз твердое с мягким. Взяли и в наследовании класса указали, что он реализует интерфейс. Это стандартное ИСПОЛЬЗОВАНИЕ интерфейсов, НО НЕ НАСЛЕДОВАНИЕ ИНТЕРФЕЙСОВ ИНТЕРФЕЙСАМИ! У интерфейсов нет наследования, есть композиция. Если угодно, если мех-м хотим называть наследованием, то наследование у интерфейсов совсем другое, нежели у классов. Есть наследование деклараций(это интерфейсы), а есть наследование деклараций + реализаций(это уже у классов). Переопределение реализаций — это обеспечение полиморфизма, ИМЕННО РАЗНОЕ ПОВЕДЕНИЕ, за счет изменения существующих уже реализаций виртуальных методов. У интерфесов нет реализаций, поэтому сами по себе они полиморфизма в понятиях, как у классов, не поддерживают. Есть только использование интерфейса как типа данных, это можно назвать НЕОБЕСПЕЧЕННЫМ ПОЛИМОРФИЗМОМ. Неужели это трудно понять, имея столько приблудов сертификационных? Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов. Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.

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

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

A>>Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода.

G>Наверное стоит начать отсюда

G>Или отсюда

Автор: Gaperton
Дата: 26.02.08

А вы, уважаемый, не думали, что речь там идет о интерфейсе класса, а не о чистом интерфесе? Да и википедия не самый авторитетный источник