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

[Дож]

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

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

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

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

[daesher]

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

Затем, что не видно только программисту. Самому компилятору (парсеру) должно быть очень даже видно - как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?

[Дож]

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

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

[daesher]

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

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

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

[Лекс Айрин]

Когда можно ждать реализацию?

когда будет время и некоторая дополнительная информация.Пока я еще не готов к написанию, продумывается структура компилятора и IDE.

[stanilar]

Шерлок Холмс оторвался от чтения и подумал:
Лекс Айрин - джавист.
Дож забыл про тип interface.

[скалогрыз]

Дож забыл про тип interface.

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

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

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

[Mikhail]

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

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

в тех случаях когда public часть меняется.

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

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

[Дож]

Дож забыл про тип interface.

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

Добавлено спустя 7 минут 11 секунд:

Ну как бы 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;


[Mirage]

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

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

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

Это недостаток реализации в языке. В Java такого не наблюдается.
А интерфейсы вещь полезная. Жаль, что нельзя применять везде по соображениям производительности и привязки к подсчету ссылок, который редко когда нужен.

[stanilar]

Придётся каждый класс дублировать

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

они нужнее когда либо... либо...

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

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

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

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

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

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

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

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

Его можно легко перекрыть.

[скалогрыз]

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

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

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

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 секунды:

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

а я делаю через общий базвый абстрактный (или пустой) класс. TWindow (window.pas) TWin32Window (win32window.pas) TLinuxWindow (linuxwindow.pas). $IFDEF-ы дальше секции uses не пускаю.

[stanilar]

Жаль, что нельзя применять везде

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

Добавлено спустя 6 минут 36 секунд:

Один раз в IMyStuff, второй раз в TMyStuff.

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

дважды

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

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

[скалогрыз]

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

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

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

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

[daesher]

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

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