Зачем два механизма ограничений?

[vitaly_l]

Я удалил бы virtual и добавил бы own (собственный)

гипотетический альтернативный язык был бы лучше

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

Поэтому я "сдаюсь" без "боя" и признаю каждого из вас - правым.

.

[Дож]

Как он действует, например, в следующем коде? Можно ли утверждать, что код и данные разделены, хотя var-секции идут в перемешку с определениями функций?

Вообще-то, обычно так не делают... функции/процедуры описывают в самом конце. Да и сейчас принято в interface писать прототипы, а не сами функции, что, имхо, более правильно. Ах да, как ни странно, да, в этом случае данные разделены, хоть вы и отошли от канонического их размещения.

Я спрашивал не про то, как делают, а про то, как «основополагающий принцип паскаля» соблюдается на уровне языка :)

Задам другой вопрос: известно, что один из основополагающих принципов ООП — это инкапсуляция, т.е. объединение данных и кода в некую единую недилимую сущность. Известно также, что паскаль поддерживает ООП конструкциями object и class. Получается, что в паскале есть два противоречащих друг другу принципа? Как так?

Да и сейчас принято в interface писать прототипы, а не сами функции, что, имхо, более правильно.

Опять же: кто предлагает писать в interface-секции сами функции? Кому Вы отвечаете? Я, наоборот, пытаюсь сократить число кода в interface-секции, вынести из него то, что по факту является частью реализации.

Сорри, не заметил. Но тогда у Вас получается объект описывается дважды. Причем, один раз в секции кода А вдруг описания не совпадут? Да и потеря компактности.

Нет, в interface-секции объявляются публичные члены, а в implementation — приватные. Дублируются дважды только заголовки публичных методов.

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

Я удалил бы virtual и добавил бы own (собственный). По умолчанию я бы сделал все методы виртуальными. Скрыл бы все методы/поля и организовал бы доступ только через property.

Для меня такое изменение убьёт паскаль и я сбегу в C++ :)

[Лекс Айрин]

Я спрашивал не про то, как делают, а про то, как «основополагающий принцип паскаля» соблюдается на уровне языка

По возможности более полно. Если, конечно, речь идет о более/менее классическом паскале.

Задам другой вопрос: известно, что один из основополагающих принципов ООП — это инкапсуляция, т.е. объединение данных и кода в некую единую недилимую сущность.

Скорее попытка. Инкапсуляции, фактически, в объектном паскале нет. Если что, Инкапсуляция это ограничение доступа внутрь объекта.

Известно также, что паскаль поддерживает ООП конструкциями object и class. Получается, что в паскале есть два противоречащих друг другу принципа? Как так?

Если честно, я тоже не понял принципиальную необходимость конструкции class. И это очень сильно мешает, так как я начинал с турбопаскаля в котором его не было. Хотя они не сильно противоречат друг другую. Боюсь, его введение процесс скорее политический.

Для меня такое изменение убьёт паскаль и я сбегу в C++

То есть, объект для Вас это такая некая запись (record) и инкапсуляция лично Вам мешает.

[Дож]

Я спрашивал не про то, как делают, а про то, как «основополагающий принцип паскаля» соблюдается на уровне языка :)

По возможности более полно. Если, конечно, речь идет о более/менее классическом паскале.

Я не вижу принципа «разделения кода и данных» в паскале, впервые слышу о существовании этого принципа и в упор не понимаю почему в текущем паскале он соблюдается, а при разбиении определения объекта на две части внезапно пропадает.

Задам другой вопрос: известно, что один из основополагающих принципов ООП — это инкапсуляция, т.е. объединение данных и кода в некую единую недилимую сущность.

Скорее попытка. Инкапсуляции, фактически, в объектном паскале нет. Если что, Инкапсуляция это ограничение доступа внутрь объекта.

Как это нет? Пишется private и данные ограничены.

Для меня такое изменение убьёт паскаль и я сбегу в C++ :)

То есть, объект для Вас это такая некая запись (record) и инкапсуляция лично Вам мешает.

Не понимаю какое отношение к этому имеет инкапсуляция.

Я хочу, чтобы мои программы шустро выполнялись, методы инлайнились, а не используемые методы библиотек не попадали в итоговый код. Если все методы будут вызываться через VMT, я всё это потеряю. Я уже буду вынужден ограничивать себя в написании вспомогательных методов.

Повсеместные виртуальные методы — это некая навязанная возможность, а я вообще не люблю, когда что-то навязывают.

ООП — это не только виртуальные методы, но и удобный, логичный синтаксический сахара. У меня большинство написанных объектов не имеют виртуальных методов.

[Лекс Айрин]

а при разбиении определения объекта на две части внезапно пропадает.

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

Как это нет? Пишется private и данные ограничены.

И вот так. И в С/с++ нет инкапсуляции. Есть модульный доступ к объектам.

При инкапсуляции вообще не должно быть левого доступа к полям объектов. Только через методы. Ну или через свойства, которые суть тоже методы.

Я хочу, чтобы мои программы шустро выполнялись, методы инлайнились, а не используемые методы библиотек не попадали в итоговый код.

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

ООП — это не только виртуальные методы, но и удобный, логичный синтаксический сахара. У меня большинство написанных объектов не имеют виртуальных методов.

И вы, при этом, теряете возможность определять потомков с нужными свойствами -- ведь при этом наличие виртуальных методов обязательно.

Люди продолжают, к сожалению, работать с объектами по старинке, методами старины Алгола. Кстати, не считаю синтактический сахар полезной практикой... это такой неиссякаемый источник ошибок... Язык, по возможности, должен быть компактным.

[Mikhail]

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

Вы ошибаетесь это фундаментальная проблема, не разрешимая в общем случае.

Люди продолжают, к сожалению, работать с объектами по старинке, методами старины Алгола.

Вообще, ООП ересь, если задуматься.

[скалогрыз]

Вообще, ООП ересь, если задуматься.

как ты полиморфизм реализуешь без OOП?

[Mirage]

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

Лекс Айрин - такое ощущение, что Вы чего-то начитались не того.

как ты полиморфизм реализуешь без OOП?

Уж чего чего, а полиморфизму можно кучей способов добиться. Например переменными процедурного типа.

[скалогрыз]

Уж чего чего, а полиморфизму можно кучей способов добиться. Например переменными процедурного типа.

очень верно, просто задача полиморфизма переляжет с хрупких плечей компилятора на программиста.
И там где VMT генерировались автоматически, просто будет написан специальный код.
... что в итоге может наткнуть на мысль: "хм, а нельзя ли как-нибудь компилятор заставить этот делать?!"

[Mirage]

скалогрыз: Именно, тут вопрос в поддержке со стороны языка. Если он поддерживает только полиморфизм через наследование, то удобно будет использовать только такой. Но если от ООП отказываться предлагают, то, видимо, взамен предлагается что-то и для полиморфизма.

[Mikhail]

как ты полиморфизм реализуешь без OOП?

Полиморфизм и ООП вещи ортогональные, как уже было замечено выше и был сформулирован задолго до ООП. Способов его реализации море. Не будем далеко ходить - интерфейсы, указатели на функции,...

Единственное что нового привнесло ООП это наследование. Кстати полиморфизм через наследование не редко приводит к архитектурным проблемам, я бы даже сказал частенько. И бинарники из-за этого растут...

Но язык одним лишь этим нововведением не спасти. Уж слишком много проблем накопилось.

Да это так - эту тему я уже поднимал, пару лет назад. Кстати, насчет экспорта, можно посмотреть как это сделано в Обероне. И к пакетам Java тоже можно присмотреться.

[Kemet]

Да это так - эту тему я уже поднимал, пару лет назад. Кстати, насчет экспорта, можно посмотреть как это сделано в Обероне. И к пакетам Java тоже можно присмотреться.

Вот не надо этого в Паскале, это я говорю как Оберонщик, ежедневно использующий Оберон в работе. Лучше используй Оберон - концепции Оберона не приживутся в Паскале, да и не Паскаль это уже будет.
А вот ВОЗМОЖНОСТЬ разделения на интерфейс и реализацию, т.е public и protected части отдельно, в секции модуля interface, а private в implementation, сделало бы [object]паскаль привлекательней.

[Mikhail]

Да это так - эту тему я уже поднимал, пару лет назад. Кстати, насчет экспорта, можно посмотреть как это сделано в Обероне. И к пакетам Java тоже можно присмотреться.

Вот не надо этого в Паскале, это я говорю как Оберонщик, ежедневно использующий Оберон в работе. Лучше используй Оберон - концепции Оберона не приживутся в Паскале, да и не Паскаль это уже будет.
А вот ВОЗМОЖНОСТЬ разделения на интерфейс и реализацию, т.е public и protected части отдельно, в секции модуля interface, а private в implementation, сделало бы [object]паскаль привлекательней.

Так я не о Паскале, а о гипотетическом языке, который мог бы прийти на смену Паскалю. Нынешний Паскаль уже не исправить, ИМХО.

[скалогрыз]

Аха! Вот нашёл подводный каменть для вынесения private секции в implementation.
Если класс объявлен таким способом:

Код: Выделить всё

type
  TMyClass = class(TObject)
  private
    fValue: Integer;
  public
    property Value: Integer read fValue write fValue;
  end;


При разделении, property в interface части должен быть объявлен способ доступа и тип данных), но реализация доступа может быть не указана.
А уже в секции implementation должна быть указана реализация (не противоречащая части в interface)
Таким вот образом:

Код: Выделить всё

interface
type
  TMyClass = class(TObject)
  public
    property Value: Integer read write;
  end;

implementation

type
  TMyClass = class
  private
    fValue: Integer;
  public
    property Value: Integer read fValue write fValue;
  end;


можно подумать что получает дубляж. Но на самом деле, тоже самое происходит и для функций с процедурами. Объявление дублируется в interface и implementation. Кстати, если я не ошибаюсь, комплятор делфи позволяет не дублировать параметры функций в implementation... но этой фичей мало кто пользуется. Ибо традиция.

Добавлено спустя 3 минуты 43 секунды:

Так я не о Паскале, а о гипотетическом языке, который мог бы прийти на смену Паскалю. Нынешний Паскаль уже не исправить, ИМХО.

Новые языки обречены на жалкое существование, ибо с Сями (их долгими библиотеками) уже мало что может потягаться. Обратная совместимость и забота о существующих библиотеках стоят на первом месте. По-этому навороты приходят в "старые" языки, превращая их в монстров!

[Kemet]

Так я не о Паскале, а о гипотетическом языке, который мог бы прийти на смену Паскалю. Нынешний Паскаль уже не исправить, ИМХО.

Так они уже созданы - Модула-2, Модула-3, Оберон-2, Активный Оберон...