freepascal.ru

Лекс Айрин писал(а):Я удалил бы virtual и добавил бы own (собственный)

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

Лекс Айрин писал(а):

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

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

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

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

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

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

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

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

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

Лекс Айрин писал(а):

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

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

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

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

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

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

Дож писал(а):а при разбиении определения объекта на две части внезапно пропадает.

Дож писал(а):Как это нет? Пишется private и данные ограничены.

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

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

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

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

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

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

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

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

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

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

Kemet писал(а):

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

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

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

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;

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

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