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

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

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

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

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

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

Сообщение Дож » 28.10.2015 10:53:22

interface - это те объявления, которые переходят в другие модули, в основную программу.

Да, так и есть, и это изменение этому способствует.

Идея разбить описание класса на две части фактически нарушает эту логику: компилятору придётся поднимать в ppu из секции implementation описание класса, как вариант - создавать "дырявое" описание для класса, но что-то надо будет делать со свойствами.

Зачем «компилятору поднимать в ppu» то, что не видно из других модулей?
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение daesher » 28.10.2015 11:51:56

Дож писал(а):Зачем «компилятору поднимать в ppu» то, что не видно из других модулей?

Затем, что не видно только программисту. Самому компилятору (парсеру) должно быть очень даже видно - как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?
daesher
постоялец
 
Сообщения: 221
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Дож » 28.10.2015 12:18:29

как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?

Я правильно понимаю, что такая проблема возникнет только со свойствами?
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение daesher » 28.10.2015 12:32:31

Дож писал(а):
как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?

Я правильно понимаю, что такая проблема возникнет только со свойствами?

Наверно да, всё зависит от реализации (похоже, в патче раскрывается всё, хотя я не уверен). Ну ещё "подвиснут" приватные виртуальные методы, хотя ничего невозможного в их сокрытии я не вижу - просто "пустое" пространство в VMT (хотя специалисты могут сказать точнее). С другой стороны, приватные виртуальные методы - вещь вообще малополезная, их суть в том, чтобы быть перекрытыми, а тут их прячут. Хотя теоретически ничего невозможного в них нет.
daesher
постоялец
 
Сообщения: 221
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 28.10.2015 12:34:10

Mirage писал(а):Когда можно ждать реализацию?

когда будет время и некоторая дополнительная информация.Пока я еще не готов к написанию, продумывается структура компилятора и IDE.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

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

Сообщение stanilar » 29.10.2015 02:59:11

Шерлок Холмс оторвался от чтения и подумал:
Лекс Айрин - джавист.
Дож забыл про тип interface.
stanilar
постоялец
 
Сообщения: 289
Зарегистрирован: 09.03.2010 19:09:02

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

Сообщение скалогрыз » 29.10.2015 05:32:07

stanilar писал(а):Дож забыл про тип interface.

Ну как бы interface получится надстройкой над ооп классом. Придётся каждый класс дублировать (как объект, и как его interface), что удваивает расходы трудопроизводства, в тех случаях когда public часть меняется.

Да, интерфейсная часть станет чистой, зато прибавится писанины. Ну и доступ к полю объекта напрямую, интерфейсы не умеют, в отличии от свойств.

Ну и в целом, это не очень правильное применение interfacе-ов. Ведь они нужнее когда нужно либо реализовать связь с кодом из другого языка (ибо стандартизированы), либо когда требуется сделать множественный интерфейсы, для одного объекта.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение Mikhail » 29.10.2015 09:38:56

скалогрыз писал(а):Ну как бы interface получится надстройкой над ооп классом.


Нет, просто по другому интерфейс в паскале не сделаешь.

скалогрыз писал(а):в тех случаях когда public часть меняется.


Публичная часть, по определению, должна меняться крайне редко и, в основном, за счет расширения, а не изменения иначе это жуткое нарушение принципа абстракции и, как следствие принципов ООП.

Вообще, при реализации через интерфейсы есть только один недостаток - более низкая производительность.
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

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

Сообщение Дож » 29.10.2015 11:14:08

stanilar писал(а):Дож забыл про тип interface.

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

Добавлено спустя 7 минут 11 секунд:
Mikhail писал(а):
скалогрыз писал(а):Ну как бы interface получится надстройкой над ооп классом.


Нет, просто по другому интерфейс в паскале не сделаешь.


Да ладно? :)
Код: Выделить всё
type
PMyInterface = ^TMyInterface;
TMyInterface = object
  procedure DoSomething; virtual; abstract;
  function GetFoo: LongInt; virtual; abstract;
end;

PBlablabla = ^TBlablabla;
TBlablabla = object(TFoofoofoo)
public type
  PInterface = ^TInterface;
  TInterface = object(TMyInterface)
  private
    FBlablabla: PBlablabla;
  public
    constructor Init(Blablabla: PBlablabla);
    procedure DoSomething; virtual;
    function GetFoo: LongInt; virtual;   
  end;
private
  FInterface: TInterface;
public
  constructor Init;
  procedure DoSomething;
  function GetFoo: LongInt;
  function AsInterface: PMyInterface;
end;

...

constructor TBlablabla.Init;
begin
  FInterface.Init(@Self);
end;

...

function TBlablabla.AsInterface: PMyInterface;
begin
  Result := @FInterface;
end;
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Mirage » 29.10.2015 23:13:35

daesher писал(а):Секция реализации (implementation) - это внутреннее, личное дело модуля, она даёт только код + пространство данных, недоступные остальным частям программы иначе как по адресам, описанным в интерфейсной части. То есть, по большому счёту, интерфейс - это то, что хранится в .ppu, а весь implementation уходит в .o (ну, в некоторой степени исключением являются блоки данных, определённые в интерфейсной части).


Думается, то, что в implementation также присутствует в .ppu. В .tpu и .dcu так точно.

Mikhail писал(а):Вообще, при реализации через интерфейсы есть только один недостаток - более низкая производительность.


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

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

Сообщение stanilar » 29.10.2015 23:27:35

скалогрыз писал(а):Придётся каждый класс дублировать


Нет. Классы реализации интерфейсов поддерживают наследование, вслед за наследуемыми интерфейсами. Или мне было непонятно, о чем Вы говорите.

скалогрыз писал(а):они нужнее когда либо... либо...

Ну не, это не полный список. Пресловутый полиморфизм, который в этой ветке пытаются реализовать в виде {$IFDEF WINDOWS}/{$IFDEF UNIX}, красивее выглядит именно на них.

Mikhail писал(а):а не изменения иначе это жуткое нарушение принципа абстракции


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

Mikhail писал(а):Вообще, при реализации через интерфейсы есть только один недостаток - более низкая производительность.


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

Именно из-за сложности отладки стараюсь избегать их в своих проектах. Как показывает практика действительная нужда в них - большая редкость.

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


Его можно легко перекрыть.
stanilar
постоялец
 
Сообщения: 289
Зарегистрирован: 09.03.2010 19:09:02

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

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

stanilar писал(а):Нет. Классы реализации интерфейсов поддерживают наследование, вслед за наследуемыми интерфейсами. Или мне было непонятно, о чем Вы говорите.

Да вот пример.
Допустим я для публичности выделил интерфес, а класс реализующий интерфес спрятан. Допустим так:
Код: Выделить всё
interface

type
  IMyStuff = interface()
  public
    procedure MakeMeHappy;
  end;

implementation

type
  TMyStuff = class(TObject, IMyStuff)
  private
    data : TMyHiddenData;
  public
    procedure MakeMeHappy;
  end;

всё чисто и хорошо, private секция TMyStuff в interface-е не светится.
Но если я хочу добавить(поменять) метод в IMyStuff, мне придётся сделать это дважды. Один раз в IMyStuff, второй раз в TMyStuff.

Добавлено спустя 1 минуту 54 секунды:
stanilar писал(а):Ну не, это не полный список. Пресловутый полиморфизм, который в этой ветке пытаются реализовать в виде {$IFDEF WINDOWS}/{$IFDEF UNIX}, красивее выглядит именно на них.

а я делаю через общий базвый абстрактный (или пустой) класс. TWindow (window.pas) TWin32Window (win32window.pas) TLinuxWindow (linuxwindow.pas). $IFDEF-ы дальше секции uses не пускаю.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение stanilar » 29.10.2015 23:42:25

Mirage писал(а):Жаль, что нельзя применять везде


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

Добавлено спустя 6 минут 36 секунд:
скалогрыз писал(а): Один раз в IMyStuff, второй раз в TMyStuff.


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

скалогрыз писал(а):дважды


Дублировать придется не дважды, а трижды.

Интерфейсы несколько отличная от классов/объектов парадигма. Думаю, в этом случае допустимо дублирование.
stanilar
постоялец
 
Сообщения: 289
Зарегистрирован: 09.03.2010 19:09:02

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

Сообщение скалогрыз » 29.10.2015 23:59:54

stanilar писал(а):Но в варианте из первого поста нужно будет продублировать целый класс два раза.

Если иметь две реализации (win32 и linux), то да, нужно не дублировать а реализовывать дважды.

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

Ведь хорошо, если интерфейс может быть использован многими классами, а тут получается 1 интерфейc обслуживает 1 класс.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение daesher » 30.10.2015 00:00:31

Mirage писал(а):Думается, то, что в implementation также присутствует в .ppu. В .tpu и .dcu так точно.

Не знаю, по логике вещей он в .ppu не нужен. Хотя это не значит, что его там нет вообще никак. Разумеется, в .tpu и .dcu он есть - ведь это - комбинированные файлы, фактически .tpu (.dcu) = .ppu + .o
daesher
постоялец
 
Сообщения: 221
Зарегистрирован: 09.03.2010 22:17:14

Пред.След.

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

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

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

Рейтинг@Mail.ru