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

VD>>Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства.
S>AFAIR это специальная версия делфи была для разработки под дотнет.

Что значит была? Была, есть и с огромной вероятностью будет. И язык там один и тот же.

VD>> Во-вторых, Дельфи начиная со второй версии поддерживает COM в котором так еж есть свойства.
S>Вроде бы интерфейсы в делфи перекочевали именно из поддержки COM-а

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

VD>>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
S>Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

Я тоже Дельфи в руки уже более 10 лет не брал. Но я не вижу как можно использовать приватные виртуальные методы.

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

VD>> Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.

H>Еще раз. Private это нестрогий ограничитель. Он не закрывает члены класса от дружественных классов (располагающихся в одном с ним модуле).

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

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

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

VD>>>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
S>>Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

VD>Я тоже Дельфи в руки уже более 10 лет не брал. Но я не вижу как можно использовать приватные виртуальные методы.

Там походу действительно private видим всему unit-у. Т.е. все классы unit-а друг другу friend-ы
А в версии 7 ввели strict private

Вот думаю, а чей это косяк с private? Не Хейлсберга ли самого?

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

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

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

H>В дельфях интерфейсы вполне себе могут иметь свойства

Это была не моя мысль, что в них свойств нет

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

S>Там походу действительно private видим всему unit-у. Т.е. все классы unit-а друг другу friend-ы
S>А в версии 7 ввели strict private

Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

Что же касается дотнетной версии Дельфи, то в ней обеспечить дружественность типом можно только если они будут вложены друг в друга. Так что я не представляю как это может быть реализовано.

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

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

S>>Там походу действительно private видим всему unit-у. Т.е. все классы unit-а друг другу friend-ы
S>>А в версии 7 ввели strict private

VD>Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

VD>Что же касается дотнетной версии Дельфи, то в ней обеспечить дружественность типом можно только если они будут вложены друг в друга. Так что я не представляю как это может быть реализовано.

Поглядел рефлектором — там IL internal трактуется как private, а IL private как strict private.

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

VD>Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

Нормальное это поведение доступ к приватным полям в модуле. Напнример для контейнеров и элементов контейнеров — это частая практика. Если мешает — strict protected и strict private решают проблему. Это особенно часто используется для написания компонентов — изоляция кода компонента от программистов его использующих. Т.е. разраюотчик компонентов пишет приоткрытый код в модуле, получает доступ, а пользователи — нет. Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

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

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

VD>>Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

A>Нормальное это поведение доступ к приватным полям в модуле.
Если бы это было нормально, так было бы везде, а не только в delphi

A>Написали бы там библиотеку компонентов — знали бы что это и с чем едят.
Вы полагаете что в философии сидят непрактикующие философы, которые не знают как с private (strict) библиотеки создавать?

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

A> Я честно не проверял, но уверен, что скомпелится. Это не стрикт приват. Хотя соглашусь, более грамотно в протектед. Я год просто на дельфях не работал, поэтому про свойства забыл у интерфейсов. Но ведь если есть свойства, следовательно могут быть сетеры и гетеры. А если еще, по вашему мнению, полиморфизм как у наследования классов, то чем они от классов отличаются?

Это точно мне вопрос? Ну да, у интерфейсов есть свойства, но они, в отличии от свойств классов/объектов, могут быть объявлены только с сеттером/геттером которые будут являться методами интерфейса.

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

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

VD> VD>> Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.

VD> H>Еще раз. Private это нестрогий ограничитель. Он не закрывает члены класса от дружественных классов (располагающихся в одном с ним модуле).

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

Private не закрывает возможность перекрытия метода в наследниках, Private ограничивает видимость членов рамками класса и (!) модуля в котором определен класс. Классы определенные в рамках одного модуля считаются дружественными и имеют доступ к Private-членам друг друга. Поэтому код:

Type

 TClassA = Class

  Private

   Procedure Proc; Virtual; Abstract;

 End;

 TClassB = Class(TClassA)

  Private

   Procedure Proc; Override;

 End;

{ TClassB }

Procedure TClassB.Proc;
Begin
 //
End;

является корректным. Для строгого ограничения применяется Strict Private. Так что, господин водитель танка, сними шлемофон и обсыпься пеплом.

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

A>Здравствуйте! Написал небольшую работу, на неформальном языке, посвященную месту типа данных в программировании. Это не учебник, а систематизация моих знаний. Подумал может быть полезна для других. Был бы очень признателен за отзывы по работе. Если она выдержит критику, то в планах написать полную 3-ю главу в журнал. Архив с примерами доступен по ссылке. Там всего 24 страницы с примерами и списком использованной литературы.

Прочитал Вашу статью. Несколько замечаний:
1. Урнировать Delphi со всеми его РАДостями. Замыливает глаза. Возьмите Python в режиме интерпретатора, к примеру. Заодно приучит человек аккуратно форматировать код
2. Повествование с сильными перескоками, без разделения. Сначала про архитектуру ЭВМ, потом про битность, потом про клепание формочек мышкой, потом про качество ПО... Вы уж определитесь с темой.
3. Текст перемежается пачками определений на полстраницы-страницу, которые зверски рвут контекст. К следующей странице забываешь, о чём читал.
4. Не совсем понятна истинная цель статьи. Если Вы обьясняете совсем новичку, я бы воздержался от глубокого анализа типов данных и ООП вообще. В этом случае стоило бы объяснить азы последовательно, на базе простеньких императивных примеров. Если же Вы пытаетесь писать для не-новичка, бОльшую часть приведённых Вами определений он уже должен знать и понимать. Зачем тогда они в тексте статьи — неясно.

Мой краткий вывод: статья похожа на вводные институтские лекции в стиле "лишь бы было". Прочитав эту кашу, Ваш племянник будет смотреть на программирование исключительно с отвращением.

В статье выделил следующие крупные темы, каждую из которых неплохо бы осветить отдельно (список вразброс):
1. Архитектура компьютера. Биты, байты, etc.
2. Языки программирования. Базовые элементы программы. Базовые управляющие конструкции.
3. RAD-среды — оставил бы на потом.
4. Требования, предъявляемые к ПО. На совсем потом. Лучше небольшой экскурс в принципы хорошего стиля.
5. Выявление ошибок в программах — после полного понимания 1 и 2.
6. Алгоритмы.
7. ООП. Как уже говорили в соседних ветках, в Вашей статье нарушение LSP в полный рост.
8. Методологии... зачем они здесь? Не стОит грузить школьника такими формализмами. ПМСМ, лучше выдать ему набор "строительных блоков", и пусть комбинирует как хочет.
9. Полиморфизм — отдельная здоровенная тема.

Чего тут точно нет, так это типов данных.

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

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

A>Мне кажется, что все это бессмысленно, так как в каждом ООП языке свое ООП. Общая методолгия для меня совсем иное, нежели все сразу, что есть во всех языках. Скорее наборот — только то, что есть у большинства общепризнанных ООП языков. Общие черты, а не все в одном. Литературы море, в каждой свое ООП, стандарта нет. UML вообще иногда мозг взрывает, особенно как у Рембо с Блахой. Давайте прекратим бессмысленный спор. Для меня что-то между интерфейсом и классом имеющим реализацию методов называется классом. Наследование реализации == наследование классов, наследование декларации == наследованию интерфейсов. Как-то так.

Так может не стОит заморачиваться на ООП? Это ж не священная корова какая. Выкиньте Вы это ООП из статьи и сконцентрируйтесь на главном.

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

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

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

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

s> A>Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

s> Вы полагаете что в философии сидят непрактикующие философы, которые не знают как с private (strict) библиотеки создавать?

Я так в этом теперь и не сомневаюсь

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

VD> VD>>Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства.

VD> S>AFAIR это специальная версия делфи была для разработки под дотнет.

VD> Что значит была? Была, есть и с огромной вероятностью будет. И язык там один и тот же.

Язык там другой. Вот в Delphi for NET язык был такой же, а в призме он другой.

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

VD> S>Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

VD> Я тоже Дельфи в руки уже более 10 лет не брал. Но я не вижу как можно использовать приватные виртуальные методы.

Оно и видно. Впрочем, это было возможно во всех версиях.

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

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

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

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

H>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично
Перечислить языки, где не точно так же?
Интересно увидель логику, согласно которой private объявление класса дает видимость уровня модуля.


s>> A>Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

s>> Вы полагаете что в философии сидят непрактикующие философы, которые не знают как с private (strict) библиотеки создавать?

H>Я так в этом теперь и не сомневаюсь
Очевидно как и в том, что библиотеки можно создавать только на delphi

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

S>Поглядел рефлектором — там IL internal трактуется как private, а IL private как strict private.

Ясно. Как всегда через задницу.

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

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

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

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

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

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

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

A>Нормальное это поведение доступ к приватным полям в модуле. Напнример для контейнеров и элементов контейнеров — это частая практика. Если мешает — strict protected и strict private решают проблему. Это особенно часто используется для написания компонентов — изоляция кода компонента от программистов его использующих. Т.е. разраюотчик компонентов пишет приоткрытый код в модуле, получает доступ, а пользователи — нет. Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

Да, все выяснилось

Автор: samius
Дата: 01.03.11

. Просто в дельфи как всегда все не как у всех.

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

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

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

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

s> Перечислить языки, где не точно так же?

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

s> Интересно увидель логику, согласно которой private объявление класса дает видимость уровня модуля.

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

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

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

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

s>> Перечислить языки, где не точно так же?

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

s>> Интересно увидель логику, согласно которой private объявление класса дает видимость уровня модуля.

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