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

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

s>> Так широко оно трактуется только в делфи.

H>В английском языке.
Я про языки программирования


s>> H>Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?

s>> Нет.

H>А должен бы...
Нет, не должен. Внутри класса доступно все что там объявлено. И границы объявления класса ограничивают видимость private. Это логично.

s>> H>List это абстракция. Детали реализации (list as dynamic array) это детали реализации. У нас ОПП или где?

s>> Если чо, то ты назвал абстракцией класс, где нет ни одного виртуального метода.

H>Опять ты с деталями... Я говорю о List (о боже, не о дотнетовском List, а вообще), как об абстракции, а ты все в детали реализации лезешь. Зачем?
А я заговорил о List как о реализации. Причем тут абстракции? Я о том, что есть структура данных Список, и логично было бы предположить что List имеет к нему отношение. Абстракцию не следует называть терминами, широко употребляемыми для других, более конкретных целей.

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

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

VD>> VD>> Это называется наследование интерфейса.

VD>> H>Класс от интерфейса не наследуется

VD>> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

H>Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса Или о чем ты?

А в чём, по-твоему, значимая разница? И то, и другое просто исторически сложившиеся названия для подтипирования, о чём тебе Влад и писал.

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

d> VD>> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

d> H>Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса Или о чем ты?

d> А в чём, по-твоему, значимая разница? И то, и другое просто исторически сложившиеся названия для подтипирования, о чём тебе Влад и писал.

Наследование интерфейса произойдет, если класс будет унаследован от предка реализующего интерфейс. Реализация интерфейса может быть нескольких видов, когда класс сам реализует контракт, когда наследует реализацию (реализация наследованием), когда использует механизмы агрегации и делегирования. Очевидно по моему

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

s> s>> Так широко оно трактуется только в делфи.

s> H>В английском языке.

s> Я про языки программирования

Отлично. Слово Private оно родом из какого языка программирования?

s> s>> H>Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?

s> s>> Нет.

s> H>А должен бы...

s> Нет, не должен. Внутри класса доступно все что там объявлено. И границы объявления класса ограничивают видимость private. Это логично.

Чудно. Вот теперь раздвинь границы класса, до границ модуля. И получается... Внутри модуля доступно все, что там объявлено. И границы модуля ограничивают видимость приватных членов классов. И в качестве дополнения: а модификатор Strict Private позволяет обозначить границы видимости внутри класса. Я же говорю, свободы больше.

s> H>Опять ты с деталями... Я говорю о List (о боже, не о дотнетовском List, а вообще), как об абстракции, а ты все в детали реализации лезешь. Зачем?

s> А я заговорил о List как о реализации. Причем тут абстракции? Я о том, что есть структура данных Список, и логично было бы предположить что List имеет к нему отношение. Абстракцию не следует называть терминами, широко употребляемыми для других, более конкретных целей.

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

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

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

s>> H>В английском языке.

s>> Я про языки программирования

H>Отлично. Слово Private оно родом из какого языка программирования?

Полагаю что первым его задействовали для сокрытия членов класса в Simula

s>> Нет, не должен. Внутри класса доступно все что там объявлено. И границы объявления класса ограничивают видимость private. Это логично.

H>Чудно. Вот теперь раздвинь границы класса, до границ модуля. И получается... Внутри модуля доступно все, что там объявлено. И границы модуля ограничивают видимость приватных членов классов. И в качестве дополнения: а модификатор Strict Private позволяет обозначить границы видимости внутри класса. Я же говорю, свободы больше.

Не надо ничего раздвигать. Модификаторы видимости по умолчанию описывают видимость вложенных вещей по отношению к непосредственно содержащей части. Так модификаторы public, protected и private типично описывают видимость членов класса по отношению к классу же. И только в делфи private описывает видимость по отношению к модулю. Это при том, что понятие модуля в ООП не формализовано.

Мне надоело что-то доказывать. Если не лень — сравни проценты популярности языков, использующих private в том и ином смысле. И ты увидишь, какой смысл является общепринятым.

s>> А я заговорил о List как о реализации. Причем тут абстракции? Я о том, что есть структура данных Список, и логично было бы предположить что List имеет к нему отношение. Абстракцию не следует называть терминами, широко употребляемыми для других, более конкретных целей.

H>Так List это одна из ключевых абстракций АТД
Во, другое дело. Я тоже когда вижу List, то подразумеваю именно то, на что ты дал ссылку. (Качество материала, правда не радует. Пишут что множество конечное и тут же приводят в пример Haskell, где список может и не являтсья конечным)

H>То, что он так реализован в дотнете, личное дело дотнета, и приводить оную реализацию в качестве аналогии к якобы неправильности семантики модификатора Private, как-то уж очень своеобразно...
Именно то же я могу сказать и о делфи — что личное дело делфи, как реализовывать видимость при указании модификатора private. Общепринятым же считается ограничение области видимости классом.

H>Как будто ты обладаешь знанием о том, каким именно образом должна быть реализована абстракция List
Конечно. Определение по твоей же ссылке:

Первая строка данного определения обозначает, что список элементов типа A (говорят: «список над A») представляет собой размеченное объединение пустого списка и декартова произведения атома типа A со списком над A.

Какие тут могут быть кривотолки? Тут разве написано что-то про массив?

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

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

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

Надоело спорить.

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

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

A>>>Нормальное это поведение доступ к приватным полям в модуле.
S>>Если бы это было нормально, так было бы везде, а не только в delphi
S>Нужно понимать, что Delphi вырос из Паскаля, в котором границы областей видимости были чётко связаны с unit задолго до вкорячивания в него OOP.
S>Именно опыт с Delphi и прочими языками привёл в конечном итоге к обобщённой модели access modifiers, принятой в дотНет.
Насколько я пошарил по ссылкам, модель access modifiers практически в текущем виде была впервые реализована в Simula до рождения самого Паскаля. А дотнет писали с Java, в котором эта модель уже работала и была срисована с C++ видимо, в котором как я полагаю, access modifiers появился тоже раньше чем в Паскале.

http://stackoverflow.com/questions/1334451/history-of-public-private-protected

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

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

d>> VD>> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

d>> H>Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса Или о чем ты?

d>> А в чём, по-твоему, значимая разница? И то, и другое просто исторически сложившиеся названия для подтипирования, о чём тебе Влад и писал.

H>Наследование интерфейса произойдет, если класс будет унаследован от предка реализующего интерфейс. Реализация интерфейса может быть нескольких видов, когда класс сам реализует контракт, когда наследует реализацию (реализация наследованием), когда использует механизмы агрегации и делегирования. Очевидно по моему

Мне не очевидно. Я не вижу, чем понятие интерфейса отличается от понятия базового класса (с некоторыми требованиями к его уровню абстрактности) + разрешения делать множественное наследование от таких базовых классов. Собственно оно (понятие интерфейса) оттуда и возникло.

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

S>http://stackoverflow.com/questions/1334451/history-of-public-private-protected
Ещё раз: концепция публичности/приватности появилась в Паскале в незапамятные времена. Тогда это называлось Модульное программирование, и было сильно лучше, чем голый C с его глобальной видимостью процедур.
Границей видимости был модуль, с его interface/implementation секциями.
Всё, что внутри implementation, видело друг друга.
Поэтому отражение той же реальности в ООП, привнесённом в готовый язык, было полностью логичным. Тем более, что стояла задача сделать OOP максимально простым — без пяти уровней доступа, модификаторов friend и прочего стуффа. Это же учебный язык.

И вообще, не существует какого-то единого "православного" способа готовить access modifiers. Их существование определяется необходимостью и возможностью. Возможность — это вычислимость предиката доступности в момент биндинга. В модели С++ не так уж много способов вычислить, в каких отношениях находится текущий компилируемый кусок кода к использованным им компонентам класса. К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.
Необходимость — это практический смысл. Даже самый базовый public/private позволяет предотвратить ненамеренную ошибку потребителя кода завязаться на то, что ты считаешь деталью реализации, или случайно сломать тебе инвариант.
protected позволяет публиковать разный уровень подробностей для потребителей и для наследников — если наследники предполагаются. Поэтому в COM, где нет наследования, нет никакого protected.

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

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

S>>http://stackoverflow.com/questions/1334451/history-of-public-private-protected
S>Ещё раз: концепция публичности/приватности появилась в Паскале в незапамятные времена.
Она там не могла появиться раньше симулы. Может быть в ADA?
S>Тогда это называлось Модульное программирование, и было сильно лучше, чем голый C с его глобальной видимостью процедур.
И C тоже еще не родился
S>Границей видимости был модуль, с его interface/implementation секциями.
S>Всё, что внутри implementation, видело друг друга.
Я имел дело с паскалем и делфи около 7и лет в том веке.

S>Поэтому отражение той же реальности в ООП, привнесённом в готовый язык, было полностью логичным. Тем более, что стояла задача сделать OOP максимально простым — без пяти уровней доступа, модификаторов friend и прочего стуффа. Это же учебный язык.
Да, я понимаю мотивы внесения в таком виде. Но было бы разумнее выбрать другое слово, а не вносить потом strict. Сам факт его внесения свидетельствует о том, что модель была неудачная.

S>И вообще, не существует какого-то единого "православного" способа готовить access modifiers. Их существование определяется необходимостью и возможностью. Возможность — это вычислимость предиката доступности в момент биндинга. В модели С++ не так уж много способов вычислить, в каких отношениях находится текущий компилируемый кусок кода к использованным им компонентам класса. К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.
Я не считаю модель доступа C++ идеальной. Но границу доступа там можно проводить набором заголовков, что и является обычной практикой.

S>Необходимость — это практический смысл. Даже самый базовый public/private позволяет предотвратить ненамеренную ошибку потребителя кода завязаться на то, что ты считаешь деталью реализации, или случайно сломать тебе инвариант.
S>protected позволяет публиковать разный уровень подробностей для потребителей и для наследников — если наследники предполагаются. Поэтому в COM, где нет наследования, нет никакого protected.

Все что я пытаюсь доказать — это то, что модель, в которой private ограничен уровнем модуля не является нормой для ООП.

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

d> H>Наследование интерфейса произойдет, если класс будет унаследован от предка реализующего интерфейс. Реализация интерфейса может быть нескольких видов, когда класс сам реализует контракт, когда наследует реализацию (реализация наследованием), когда использует механизмы агрегации и делегирования. Очевидно по моему

d> Мне не очевидно. Я не вижу, чем понятие интерфейса отличается от понятия базового класса (с некоторыми требованиями к его уровню абстрактности) + разрешения делать множественное наследование от таких базовых классов. Собственно оно (понятие интерфейса) оттуда и возникло.

Я уже писал об этом:

Абстрактный класс и интерфейс это далеко не одно и то же. Абстрактный класс может являться одним из ранних предков в иерархии, а интерфейс это просто контракт, который можно исполнить. То есть, реализация интерфейса вообще ни как не связана с наследованием, в отличии от абстрактного класса.

Если уж совсем просто, то от абстрактного класса можно наследоваться, а от интерфейса нельзя. Тот факт, что в C++ интерфейс и абстрактный класс есть одно и тоже — сути не меняет. Это особенности реализации.

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

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

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

S>>>http://stackoverflow.com/questions/1334451/history-of-public-private-protected
S>>Ещё раз: концепция публичности/приватности появилась в Паскале в незапамятные времена.
S>Она там не могла появиться раньше симулы. Может быть в ADA?
Симула ни при чём. Вы понимаете, что речь идёт про тот Паскаль, в котором не было ООП?
S>Я имел дело с паскалем и делфи около 7и лет в том веке.
Это хорошо для вас. Я начал года на 3 раньше.

S>Да, я понимаю мотивы внесения в таком виде. Но было бы разумнее выбрать другое слово, а не вносить потом strict. Сам факт его внесения свидетельствует о том, что модель была неудачная.
Выбирали одни люди, в 1980х, а вносили другие, через 25 лет. О чём вы говорите?

S>Я не считаю модель доступа C++ идеальной. Но границу доступа там можно проводить набором заголовков, что и является обычной практикой.
Покажите мне access modifier в С++, который позволяет провести границу доступа по набору заголовков. Обычной практикой всё же является public/private, а не #ifdef _included_from_same_assembly_

S>Все что я пытаюсь доказать — это то, что модель, в которой private ограничен уровнем модуля не является нормой для ООП.
Зато является нормой для модульного программирования.
А ещё Private — это такая порностудия. Какие выводы можно из этого сделать?
Я думаю, такие же, как и из того, raise и throw в разных языках значат одно и то же: ключевые слова контекстно-зависимы. Не имеет смысла объяснять японцам то, что им не стоило называть гору ямой.

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

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

S>Симула ни при чём. Вы понимаете, что речь идёт про тот Паскаль, в котором не было ООП?
Да, и в нем не было слова private, были только секции interface/implementation, некие аналоги h,c файлов.

S>>Да, я понимаю мотивы внесения в таком виде. Но было бы разумнее выбрать другое слово, а не вносить потом strict. Сам факт его внесения свидетельствует о том, что модель была неудачная.
S>Выбирали одни люди, в 1980х, а вносили другие, через 25 лет. О чём вы говорите?
О том что другие люди таки посчитали что область видимости private слишком широка.

S>>Я не считаю модель доступа C++ идеальной. Но границу доступа там можно проводить набором заголовков, что и является обычной практикой.
S>Покажите мне access modifier в С++, который позволяет провести границу доступа по набору заголовков. Обычной практикой всё же является public/private, а не #ifdef _included_from_same_assembly_
Я отвечал на это

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

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

S>>Все что я пытаюсь доказать — это то, что модель, в которой private ограничен уровнем модуля не является нормой для ООП.
S>Зато является нормой для модульного программирования.
разве в оригинальном паскале было слово private?

S>А ещё Private — это такая порностудия. Какие выводы можно из этого сделать?
S>Я думаю, такие же, как и из того, raise и throw в разных языках значат одно и то же: ключевые слова контекстно-зависимы. Не имеет смысла объяснять японцам то, что им не стоило называть гору ямой.
Я лишь пытаюсь показать что обычно у этого модификатора другой смысл. Использовать private в делфи без оговорок в статьях, имеющих отношение к ООП — плохая идея.

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

S>О том что другие люди таки посчитали что область видимости private слишком широка.
Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи. Вы сейчас рассуждаете, как неопытный архитектор, глядя на гостиницу "Каравелла" в Лиссабоне: "чего это они не предусмотрели канализацию при постройке". Гостиницу строили и перестраивали четыреста лет. По-моему, можно даже невооружённым мозгом понять, почему в 1680 году строители не заложились на лифт и канализацию, а также почему в 1980 их всё-таки добавили.
Поймите, разработчики версии 5.0 не могли предусмотреть появления интеграции с дотнетом в версии 15.0. А разработчики версии 15.0 не могли волшебным образом изменить значение существующего ключевого слова, так же как реконструкторы гостиницы не могли волшебным образом пропустить трубы в стенах древнего здания.

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

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

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

S>разве в оригинальном паскале было слово private?
В TP 5.0 — было. Хейльсберг поставил перед собой задачу сделать язык, пригодный для изучения ООП. Он гордился тем, что добился этого всего четырьмя ключевыми словами. То, что вы предлагаете, означало как минимум на 20% больше новых ключевых слов.
S>Я лишь пытаюсь показать что обычно у этого модификатора другой смысл. Использовать private в делфи без оговорок в статьях, имеющих отношение к ООП — плохая идея.
(Вздыхает). То, что вы называете "oбычно" — продукт совсем другой эпохи. В 1989 никаких "обычно" ещё не было. В том же году в С++ добавили access modifier protected. В Simula никаких private не было.
А в наши дни, конечно же, использовать Delphi для примеров в статьях не про Delphi — неожиданно. Тем более при рассуждении о типизации — дельфийская система типов изобилует причудливыми странностями ничуть не меньше, чем древнеэльфийский у JRRT.

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


S>>Я лишь пытаюсь показать что обычно у этого модификатора другой смысл. Использовать private в делфи без оговорок в статьях, имеющих отношение к ООП — плохая идея.
S>(Вздыхает). То, что вы называете "oбычно" — продукт совсем другой эпохи. В 1989 никаких "обычно" ещё не было. В том же году в С++ добавили access modifier protected. В Simula никаких private не было.
S>А в наши дни, конечно же, использовать Delphi для примеров в статьях не про Delphi — неожиданно. Тем более при рассуждении о типизации — дельфийская система типов изобилует причудливыми странностями ничуть не меньше, чем древнеэльфийский у JRRT.

Мне дельфи нравится, очень, больше, чес C#. Я его знаю наизусть, у меня компоненты правили исходники во время проектирования программы. Поэтому примеры на дельфях. На .NET и C# легче писать проги, но он чисто ООП язык. А дельфи гибридный язык, сохраняет императивный синтаксис и процедурный подход в программировании. Не всЁ в жизни является объектами. Число 7 мне трудно представить как объект. Пример: сложить объект Семи с Объектом трех получим объект десяти!!! Что за чушь! Для инженерных прикладных задач ООП не годится. В полной 3 главе будет обоснование этого.

Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов. Наследования интерфейсов нет. Не путайте твердое с мягким.

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

A>Мне дельфи нравится, очень, больше, чес C#. Я его знаю наизусть, у меня компоненты правили исходники во время проектирования программы. Поэтому примеры на дельфях. На .NET и C# легче писать проги, но он чисто ООП язык. А дельфи гибридный язык, сохраняет императивный синтаксис и процедурный подход в программировании.
Вообще-то С# тоже гибридный. Негибридов в наше время, наверное, уже и не осталось. Ну, разве что джава в версиях примерно так 1.3.

A>Не всЁ в жизни является объектами. Число 7 мне трудно представить как объект. Пример: сложить объект Семи с Объектом трех получим объект десяти!!! Что за чушь!
Ну, это вы зря. В том смысле, что тройки и семёрки не ведут себя как объекты — это правда. Но эмулировать поведение value-типов на ООП можно. См. например smalltalk. Главное — иметь в виду, что существует ровно один объект, соответствующий числу 7, вечный и неизменный. Тогда никакой чуши — посылаем объекту 7 сообщение "прибавь объект 3", он возвращает нам объект 10.
И объект 5, получив сообщение "прибавить объект 5" получает тот же самый объект 5, и возвращает ровно тот же объект 10, что и в примере с 7+3.
То есть у нас нет проблемы различения эквивалентности по ссылке и по значению.
Попытки моделировать арифметику на изменяемых объектах, конечно же обречены на провал. В результате получаем, что это, конечно же, не ООП — из трёх основ мы от двух отказываемся.

Вообще, арифметику можно эмулировать практически на чём угодно. К примеру, можно на чистых функциях (если язык поддерживает функции как первоклассные сущности).

A>Для инженерных прикладных задач ООП не годится. В полной 3 главе будет обоснование этого.
Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

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

A>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов. Наследования интерфейсов нет. Не путайте твердое с мягким.
Непонятно. Как раз разные реализации методов и подразумеваются. Попробуйте подразуметь некую "одинаковую" реализацию метода произвольного интерфейса в любом современном ООЯ.
К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.

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

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

Уточню как я понимаю интерфейсы внутри языка программирования(а не как механизм межпроцессного взаимодействия). Для меня это перечень методов(св-ва тоже можно выражать в виде декларации методов, т.е. методы называть как свойства в виде, например, существительного), декларация. Оно же ведь называется интерфейсом!. Как правильно кто-то тут сказал, это можно назвать контрактом.
Реализации методов в интерфейсах для меня нет. Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода. Наследования интерфейсов с поддержкой полиморфизма(разной реализации виртуальных методов) в иерархии интерфейсов нет. Есть включение(агрегация) деклараций методов наследниками. Интерфейсы другие интерфейсы не реализуют.
Класс — уже совсем другое. Там идет реализация поведения, поэтому там наследование с полиморфизмом. Класс-наследник может менять поведение класса-предка в рамках инварианта(контракта). Вот так наиболее четкое описание разницы между интерфейсом и классом языка программирования..