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

Проектирование и разработка идеального средства программирования.

Модератор: Модераторы

Пожалуйста, прочтите верхний пост, и скажите какой подход к дизайну языка лучше.

Лучше как сейчас
10
53%
Лучше так, как сейчас, и никак иначе!
2
11%
Лучше без private и strict (но с остальными секциями)
4
21%
Мне пофиг
1
5%
Лучше убрать interface и implementation
2
11%
 
Всего голосов : 19

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

Сообщение vitaly_l » 24.10.2015 14:17:43

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

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

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

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

.
Последний раз редактировалось vitaly_l 24.10.2015 14:42:05, всего редактировалось 1 раз.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

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

Сообщение Дож » 24.10.2015 14:33:44

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


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


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

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

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

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

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

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

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

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

Для меня такое изменение убьёт паскаль и я сбегу в C++ :)
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Лекс Айрин » 24.10.2015 15:06:53

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


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

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

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

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


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

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


То есть, объект для Вас это такая некая запись (record) и инкапсуляция лично Вам мешает.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

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

Сообщение Дож » 24.10.2015 15:49:58

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


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

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

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

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

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

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


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

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

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

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

ООП — это не только виртуальные методы, но и удобный, логичный синтаксический сахара. У меня большинство написанных объектов не имеют виртуальных методов.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Лекс Айрин » 24.10.2015 16:38:48

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


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

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


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

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

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


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


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

Люди продолжают, к сожалению, работать с объектами по старинке, методами старины Алгола. Кстати, не считаю синтактический сахар полезной практикой... это такой неиссякаемый источник ошибок... Язык, по возможности, должен быть компактным.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

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

Сообщение Mikhail » 24.10.2015 18:08:48

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


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


Вообще, ООП ересь, если задуматься. :wink:
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

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

Сообщение скалогрыз » 24.10.2015 19:08:14

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

как ты полиморфизм реализуешь без OOП?
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение Mirage » 24.10.2015 20:42:50

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

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

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


Уж чего чего, а полиморфизму можно кучей способов добиться. Например переменными процедурного типа.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение скалогрыз » 24.10.2015 20:46:46

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

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

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

Сообщение Mirage » 24.10.2015 22:04:55

скалогрыз: Именно, тут вопрос в поддержке со стороны языка. Если он поддерживает только полиморфизм через наследование, то удобно будет использовать только такой. Но если от ООП отказываться предлагают, то, видимо, взамен предлагается что-то и для полиморфизма.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение Mikhail » 24.10.2015 22:35:30

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


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

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

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


Да это так - эту тему я уже поднимал, пару лет назад. :( Кстати, насчет экспорта, можно посмотреть как это сделано в Обероне. И к пакетам Java тоже можно присмотреться.
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

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

Сообщение Kemet » 25.10.2015 12:13:22

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

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

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

Сообщение Mikhail » 25.10.2015 20:51:02

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

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

Так я не о Паскале, а о гипотетическом языке, который мог бы прийти на смену Паскалю. Нынешний Паскаль уже не исправить, ИМХО. :(
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

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

Сообщение скалогрыз » 25.10.2015 23:30:13

Аха! Вот нашёл подводный каменть для вынесения 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 секунды:
Mikhail писал(а):Так я не о Паскале, а о гипотетическом языке, который мог бы прийти на смену Паскалю. Нынешний Паскаль уже не исправить, ИМХО.
Новые языки обречены на жалкое существование, ибо с Сями (их долгими библиотеками) уже мало что может потягаться. Обратная совместимость и забота о существующих библиотеках стоят на первом месте. По-этому навороты приходят в "старые" языки, превращая их в монстров!
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение Kemet » 26.10.2015 00:07:44

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

Так они уже созданы - Модула-2, Модула-3, Оберон-2, Активный Оберон...
Kemet
постоялец
 
Сообщения: 241
Зарегистрирован: 10.02.2010 19:28:32
Откуда: Временно оккупированная территория

Пред.След.

Вернуться в Компилятор / язык программирования

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4

Рейтинг@Mail.ru