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

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

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

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

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

H>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

Это не нормально с точки зрения языка (английского). Модификаторы доступа задаются для членов класса, но почему-то рассматриваются на уровне модуля. Было бы логично ввести модификтатор module private.

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

H>В этих языках есть понятие пакета/модуля?

Да, сборки.

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

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

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

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

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

VD> H>В этих языках есть понятие пакета/модуля?

VD> Да, сборки.

Сборки это не модули. С практической точки зрения связанность кода в рамках модуля допустима т.к. модуль укрупняет инкапсуляцию, а все что под капотом есть детали реализации. Публичные-то контракты от этого не страдают

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

VD> Это не нормально с точки зрения языка (английского). Модификаторы доступа задаются для членов класса, но почему-то рассматриваются на уровне модуля. Было бы логично ввести модификтатор module private.

Трактовка Private достаточно широкая. Как один из вариантов — "закрытый, не являющийся доступным для всех" (c) Apresyan.

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

s> H>А логика проста. Модуль есть функциональная единица. Классы объявленные в модуле являются (в общем случае) реализацией его функциональности.

s> ... поэтому "private" внутри класса открывает доступ на уровне модуля вопреки тому как это принято. Я верно понял логику?

Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.

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

s> s>> A>Нормальное это поведение доступ к приватным полям в модуле.

s> s>> Если бы это было нормально, так было бы везде, а не только в delphi

s> H>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

s> видимо речь о "private part of the package declaration", т.е. о типах, а не о членах класса/записи? В общем, в ADA не точно так же.

Там просто другая идеология ООП. Поэтому прямой кальки и не получится. Но там есть внутренние пакеты, дочерние пакеты (расширяющие родительский и имеющие доступ к закрытым членам).

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

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

s>> H>А логика проста. Модуль есть функциональная единица. Классы объявленные в модуле являются (в общем случае) реализацией его функциональности.

s>> ... поэтому "private" внутри класса открывает доступ на уровне модуля вопреки тому как это принято. Я верно понял логику?

H>Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.
Правильно, вопреки. В паскаль тащили ООП гораздо позже, чем устоялись термины.

в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

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

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

s>> видимо речь о "private part of the package declaration", т.е. о типах, а не о членах класса/записи? В общем, в ADA не точно так же.

H>Там просто другая идеология ООП. Поэтому прямой кальки и не получится. Но там есть внутренние пакеты, дочерние пакеты (расширяющие родительский и имеющие доступ к закрытым членам).

Раз кальки не получается, то и аргумент про ADA не состоялся.

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

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

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

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

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

s> H>Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.

s> Правильно, вопреки. В паскаль тащили ООП гораздо позже, чем устоялись термины.

s> в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

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

s> И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

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

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

H>Сборки это не модули.

С чего бы это?

H>С практической точки зрения связанность кода в рамках модуля допустима т.к. модуль укрупняет инкапсуляцию, а все что под капотом есть детали реализации. Публичные-то контракты от этого не страдают

Укрупнение инкапсуляции — это очень смешно. Хорошее, полит-корректное название для нарушения инкапсуляции. Я не знаю как там обстоят дела с вашей "практической точки зрения", но если даже забыть про ООП и т.п., на практике есть такая штука как АТД. И возможность залезть в кишки АТД — это недостаток, а не преимущество.

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

В общем-то понятно зачем в Дельфи дали возможность залезать в кишки типов. Периодически бывает ситуация когда несколько типов должны быть очень тесно связаны (например, по соображениям производительности). Пакеты позволяет инкапсулировать такое залезание. Однако это никак не оправдывает столь странного имени модификатора доступа. А strict privat звучит просто смешно. "- Ворона, ворона сколько у тебя ножек? — Две! Особенно левая!!!".

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

VD>> Это не нормально с точки зрения языка (английского). Модификаторы доступа задаются для членов класса, но почему-то рассматриваются на уровне модуля. Было бы логично ввести модификтатор module private.

H>Трактовка Private достаточно широкая. Как один из вариантов — "закрытый, не являющийся доступным для всех" (c) Apresyan.

Что это меняет? По факту то он получается открытым для других типов.

В общем, мне этот спор не интересен. Всем кто считает такое именование нормальным счастливо оставаться со своим мнением.

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

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

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

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

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

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

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

s>> H>Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.

s>> Правильно, вопреки. В паскаль тащили ООП гораздо позже, чем устоялись термины.

s>> в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

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

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

s>> И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

H>List это абстракция. Детали реализации (list as dynamic array) это детали реализации. У нас ОПП или где?
Если чо, то ты назвал абстракцией класс, где нет ни одного виртуального метода.

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

VD> H>Сборки это не модули.

VD> С чего бы это?

По определению. Модуль относится к исходному коду, сборка к бинарному.

VD> H>С практической точки зрения связанность кода в рамках модуля допустима т.к. модуль укрупняет инкапсуляцию, а все что под капотом есть детали реализации. Публичные-то контракты от этого не страдают

VD> Укрупнение инкапсуляции — это очень смешно. Хорошее, полит-корректное название для нарушения инкапсуляции. Я не знаю как там обстоят дела с вашей "практической точки зрения", но если даже забыть про ООП и т.п., на практике есть такая штука как АТД. И возможность залезть в кишки АТД — это недостаток, а не преимущество.

А причем тут АТД?

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

Я очень рад за них. А кто тебе сказал, что концепция модулей может существовать только в твоем идеализированном осознании оной?

VD> В общем-то понятно зачем в Дельфи дали возможность залезать в кишки типов. Периодически бывает ситуация когда несколько типов должны быть очень тесно связаны (например, по соображениям производительности). Пакеты позволяет инкапсулировать такое залезание. Однако это никак не оправдывает столь странного имени модификатора доступа. А strict privat звучит просто смешно. "- Ворона, ворона сколько у тебя ножек? — Две! Особенно левая!!!".

Очень правильно звучит. Private допускает вольное трактование, Strict указывает на буквальное трактование

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

VD> H>Трактовка Private достаточно широкая. Как один из вариантов — "закрытый, не являющийся доступным для всех" (c) Apresyan.

VD> Что это меняет? По факту то он получается открытым для других типов.

В рамках одного модуля и только.

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

s> s>> в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

s> H>Это слово трактуется весьма широко.

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

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

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

s> Нет.

А должен бы...

s> s>> И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

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

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

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

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

VD>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.

private в Делфи имеет такойже коэффициент кривизны как и internal в дотнете.