скалогрыз писал(а):а вот иначе, в С++ сделать просто невозможно, из-за структуры языка. Ибо всё что использует .c/.cpp должно быть где-то описано в header-е.
В Си++ модулей нет, как и области видимости модулей.
В Си++ модулей нет, как и области видимости модулей.
Вот о чём и речь (хотя сишные .h - та ещё проблема).
В общем, в паскале есть аналогия - всё, что используют другие модули, должно быть описано где-то в части interface.
Статистика: Добавлено daesher — 31.10.2015 07:48:34
]]>
Mikhail писал(а):По тем же причинам что и в Паскале, нет никаких проблем сделать иначе.
а вот иначе, в С++ сделать просто невозможно, из-за структуры языка. Ибо всё что использует .c/.cpp должно быть где-то описано в header-е.
В Си++ модулей нет, как и области видимости модулей.
Статистика: Добавлено скалогрыз — 30.10.2015 15:24:12
]]>
Дож писал(а):Да ладно? 
Проще так, если уж на то пошло
Код:
PInterface = ^TInterface;
TInterface = record
obj: pointer;
Metod1: procedure (AObj: pointer; ...);
Metod2: procedure (AObj: pointer; ...);
...
end;
Ну а вообще, я о поддержке в языке говорил.
Добавлено спустя 3 минуты 5 секунд:
скалогрыз писал(а):Второй пример, почему в С++, описание класса должно идти целиком.
По тем же причинам что и в Паскале, нет никаких проблем сделать иначе.
Статистика: Добавлено Mikhail — 30.10.2015 07:42:41
]]>
stanilar писал(а):Есть языковые конструкции, от которых нельзя отказаться. Если вместе с ними, язык содержит все необходимые возможности, то нет острой необходимости плодить сущности.
от языковых конструкций никто не предлагает отказатся. Новые сущности не предлагают плодить.
Наоборот, предлагают уточнить описание существующих и сделать его более модульным.
При этом 100% обратная совместимость. Т.е. все private можно оставить в interface.
Например, почему в С++, описание класса должно идти целиком?
Потому что в С++ классы могут легко располагатся в стеке, и полный размер должен быть известен каждому кусочку кода, на момент компиляции.
В Паскале, размер класса нужен только на момент исполнения, так что скрытую "private" часть класса, можно спрятать в implementation. (Но даже в этом случае, размер экземпляра будет известен на момент компиляции)
Второй пример, почему в С++, описание класса должно идти целиком.
Потому что в С++ есть "друзья" которые имеют доступ к приватным полям класса, естественно они должны знать о приватных полях.
В Паскале "друзей" нет, а есть область видимости модуля. Весь код, находящийся в том же модуле имеет доступ к "private" секции. Весь модуль - "друг". Если "private" поля вынести в implementation, область видимости это никак не нарушит.
Статистика: Добавлено скалогрыз — 30.10.2015 04:43:48
]]>
]]>
stanilar писал(а):Вместе с остальными языковыми возможностями, они дополняют язык до нужного соответствия.
смысл изменения в том, чтобы минимизировать использование различных языковых возможностей.
Статистика: Добавлено скалогрыз — 30.10.2015 00:33:55
]]>
скалогрыз писал(а):Интерфейсы это подобный функционал, но никак не идентичный желаемому.
Вместе с остальными языковыми возможностями, они дополняют язык до нужного соответствия.
Статистика: Добавлено stanilar — 29.10.2015 23:23:04
]]>
stanilar писал(а):Разговор изначально зашел про новую языковую возможность. У меня просто появилась мысль о том, что в языке уже все есть.
Интерфейсы это подобный функционал, но никак не идентичный желаемому.
Статистика: Добавлено скалогрыз — 29.10.2015 23:12:28
]]>
скалогрыз писал(а):делаю через общий базвый абстрактный (или пустой) класс.
Когда зависимости удачно спроектированы - это хорошо. Но так получается не всегда. Есть определенный плюс в том, что интерфейсы позволяют сделать надстройку над уже существующими отношениями классов.
скалогрыз писал(а):1 интерфейc обслуживает 1 класс.
Разговор изначально зашел про новую языковую возможность. У меня просто появилась мысль о том, что в языке уже все есть.
Статистика: Добавлено stanilar — 29.10.2015 23:09:04
]]>
Mirage писал(а):Думается, то, что в implementation также присутствует в .ppu. В .tpu и .dcu так точно.
Не знаю, по логике вещей он в .ppu не нужен. Хотя это не значит, что его там нет вообще никак. Разумеется, в .tpu и .dcu он есть - ведь это - комбинированные файлы, фактически .tpu (.dcu) = .ppu + .o
Статистика: Добавлено daesher — 29.10.2015 23:00:31
]]>
stanilar писал(а):Но в варианте из первого поста нужно будет продублировать целый класс два раза.
Если иметь две реализации (win32 и linux), то да, нужно не дублировать а реализовывать дважды.
Собственно в этом и разница, что при использовании объектов напрямую, код получается всегда полезный.
А при использовании interfacе-а, как морды к одному единственному классу, получается одно дополнительное "бюракратическое" объявление.
Ведь хорошо, если интерфейс может быть использован многими классами, а тут получается 1 интерфейc обслуживает 1 класс.
Статистика: Добавлено скалогрыз — 29.10.2015 22:59:54
]]>
Mirage писал(а):Жаль, что нельзя применять везде
Парадокс: после появления механизма интерфейсов в ООП, лапше-код на них запросто превосходит лапшу из процедурного. Именно благодаря тому, что один и тот-же интерфейс может быть реализован в разных объектах, и в произвольном порядке вызван в ран-тайм.
Добавлено спустя 6 минут 36 секунд:
скалогрыз писал(а): Один раз в IMyStuff, второй раз в TMyStuff.
Но в варианте из первого поста нужно будет продублировать целый класс два раза.
скалогрыз писал(а):дважды
Дублировать придется не дважды, а трижды.
Интерфейсы несколько отличная от классов/объектов парадигма. Думаю, в этом случае допустимо дублирование.
Статистика: Добавлено stanilar — 29.10.2015 22:49:01
]]>
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 не пускаю.
Статистика: Добавлено скалогрыз — 29.10.2015 22:38:07
]]>
скалогрыз писал(а):Придётся каждый класс дублировать
Нет. Классы реализации интерфейсов поддерживают наследование, вслед за наследуемыми интерфейсами. Или мне было непонятно, о чем Вы говорите.
скалогрыз писал(а):они нужнее когда либо... либо...
Ну не, это не полный список. Пресловутый полиморфизм, который в этой ветке пытаются реализовать в виде {$IFDEF WINDOWS}/{$IFDEF UNIX}, красивее выглядит именно на них.
Mikhail писал(а):а не изменения иначе это жуткое нарушение принципа абстракции
Всегда думал что в программировании абстракция применяется к отношению код-задача, а не как подход к развитию кодовой базы.
Mikhail писал(а):Вообще, при реализации через интерфейсы есть только один недостаток - более низкая производительность.
Не настолько более, чтоб с этой потерей считаться. Вообще, у проектов на интерфейсах есть более впечатляющий недостаток - сложность отладки. А сложность в том, что при работе с классами в коде порядок наследования прямо отражен в объявлении класса. А вот когда один и тот-же интерфейс может быть взять из самых интересных объектов, то тут уже не всегда без отладчика можно понять что и как может/должно работать.
Именно из-за сложности отладки стараюсь избегать их в своих проектах. Как показывает практика действительная нужда в них - большая редкость.
Добавлено спустя 2 минуты 10 секунд:
Mirage писал(а):и привязки к подсчету ссылок, который редко когда нужен.
Его можно легко перекрыть.
Статистика: Добавлено stanilar — 29.10.2015 22:29:45
]]>
daesher писал(а):Секция реализации (implementation) - это внутреннее, личное дело модуля, она даёт только код + пространство данных, недоступные остальным частям программы иначе как по адресам, описанным в интерфейсной части. То есть, по большому счёту, интерфейс - это то, что хранится в .ppu, а весь implementation уходит в .o (ну, в некоторой степени исключением являются блоки данных, определённые в интерфейсной части).
Думается, то, что в implementation также присутствует в .ppu. В .tpu и .dcu так точно.
Mikhail писал(а):Вообще, при реализации через интерфейсы есть только один недостаток - более низкая производительность.
Это недостаток реализации в языке. В Java такого не наблюдается.
А интерфейсы вещь полезная. Жаль, что нельзя применять везде по соображениям производительности и привязки к подсчету ссылок, который редко когда нужен.
Статистика: Добавлено Mirage — 29.10.2015 22:13:35
]]>
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;
Статистика: Добавлено Дож — 29.10.2015 10:21:19
]]>
скалогрыз писал(а):Ну как бы interface получится надстройкой над ооп классом.
Нет, просто по другому интерфейс в паскале не сделаешь.
скалогрыз писал(а):в тех случаях когда public часть меняется.
Публичная часть, по определению, должна меняться крайне редко и, в основном, за счет расширения, а не изменения иначе это жуткое нарушение принципа абстракции и, как следствие принципов ООП.
Вообще, при реализации через интерфейсы есть только один недостаток - более низкая производительность.
Статистика: Добавлено Mikhail — 29.10.2015 08:38:56
]]>
stanilar писал(а):Дож забыл про тип interface.
Ну как бы interface получится надстройкой над ооп классом. Придётся каждый класс дублировать (как объект, и как его interface), что удваивает расходы трудопроизводства, в тех случаях когда public часть меняется.
Да, интерфейсная часть станет чистой, зато прибавится писанины. Ну и доступ к полю объекта напрямую, интерфейсы не умеют, в отличии от свойств.
Ну и в целом, это не очень правильное применение interfacе-ов. Ведь они нужнее когда нужно либо реализовать связь с кодом из другого языка (ибо стандартизированы), либо когда требуется сделать множественный интерфейсы, для одного объекта.
Статистика: Добавлено скалогрыз — 29.10.2015 04:32:07
]]>
Дож забыл про тип interface.
Статистика: Добавлено stanilar — 29.10.2015 01:59:11
]]>
Mirage писал(а):Когда можно ждать реализацию?
когда будет время и некоторая дополнительная информация.Пока я еще не готов к написанию, продумывается структура компилятора и IDE.
Статистика: Добавлено Лекс Айрин — 28.10.2015 11:34:10
]]>
Дож писал(а):
Я правильно понимаю, что такая проблема возникнет только со свойствами?
как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?
Я правильно понимаю, что такая проблема возникнет только со свойствами?
Наверно да, всё зависит от реализации (похоже, в патче раскрывается всё, хотя я не уверен). Ну ещё "подвиснут" приватные виртуальные методы, хотя ничего невозможного в их сокрытии я не вижу - просто "пустое" пространство в VMT (хотя специалисты могут сказать точнее). С другой стороны, приватные виртуальные методы - вещь вообще малополезная, их суть в том, чтобы быть перекрытыми, а тут их прячут. Хотя теоретически ничего невозможного в них нет.
Статистика: Добавлено daesher — 28.10.2015 11:32:31
]]>
как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?
Я правильно понимаю, что такая проблема возникнет только со свойствами?
Статистика: Добавлено Дож — 28.10.2015 11:18:29
]]>
Дож писал(а):Зачем «компилятору поднимать в ppu» то, что не видно из других модулей?
Затем, что не видно только программисту. Самому компилятору (парсеру) должно быть очень даже видно - как иначе он заменит свойства на вызовы приватных методов и доступ к приватным полям?
Статистика: Добавлено daesher — 28.10.2015 10:51:56
]]>
interface - это те объявления, которые переходят в другие модули, в основную программу.
Да, так и есть, и это изменение этому способствует.
Идея разбить описание класса на две части фактически нарушает эту логику: компилятору придётся поднимать в ppu из секции implementation описание класса, как вариант - создавать "дырявое" описание для класса, но что-то надо будет делать со свойствами.
Зачем «компилятору поднимать в ppu» то, что не видно из других модулей?
Статистика: Добавлено Дож — 28.10.2015 09:53:22
]]>
Идея разбить описание класса на две части фактически нарушает эту логику: компилятору придётся поднимать в ppu из секции implementation описание класса, как вариант - создавать "дырявое" описание для класса, но что-то надо будет делать со свойствами.
Т.е., фактически мы всё дальше уходим от машинного представления к человеческому, но не связанному с машинным, что может порождать непонимание и коллизии (которые уже являются спутником последних версий FPC).
Статистика: Добавлено daesher — 28.10.2015 07:49:39
]]>
Mikhail писал(а):Проблема документирования надуманная, ИМХО, полно средств ее генерации из комментариев и все равно где именно в модуле она расположена.
Генерация используется, в основном, для создания веб-страничек с документацией. При работе с библиотекой веб-страничку неудобно использовать. Куда удобнее сразу видеть описание класса/метода перейдя к нему по ctrl+click.
А тюториалов это не заменит конечно.
Насчет порядка полей согласен, проблема.
Лекс Айрин писал(а):К тому же, если указанный способ решит проблему, то неважно насколько он будет медленным или дилетантским -- он будет работать, а значит профи смогут его улучшить. А не смогут, так придумают новый. А не решит, так я посмотрю где ошибка(и) и сделаю заново, с учетом этого.
Когда можно ждать реализацию?
Статистика: Добавлено Mirage — 27.10.2015 22:24:06
]]>
Mikhail писал(а):
Абстрактные типы данных. например Вам нужно внутренние (приватные) поля разместить в определенном порядке, протектед не годится, т.к. это именно внутренняя приватная часть.
Дож писал(а):Под АТД такое подразумевается? Такое должно быть разрешено в любом случае.
Абстрактные типы данных. например Вам нужно внутренние (приватные) поля разместить в определенном порядке, протектед не годится, т.к. это именно внутренняя приватная часть.
В чём проблема все поля положить в implementation и сделать доступ к ним через свойства?
Дож писал(а):Комментарии для таких генераторов, как правило, очень механически написаны, с излишним синтаксисом и т.д. — ухудшают читаемость и кода, и неочевидной информации редко содержат.
Это уже от автора зависит, а не от системы комментирования. :)
При прочих равных один подход к комментированию среднестатистически лучше другого.
Статистика: Добавлено Дож — 27.10.2015 11:28:57
]]>
Дож писал(а):Под АТД такое подразумевается? Такое должно быть разрешено в любом случае.
Абстрактные типы данных. например Вам нужно внутренние (приватные) поля разместить в определенном порядке, протектед не годится, т.к. это именно внутренняя приватная часть.
Дож писал(а):Комментарии для таких генераторов, как правило, очень механически написаны, с излишним синтаксисом и т.д. — ухудшают читаемость и кода, и неочевидной информации редко содержат.
Это уже от автора зависит, а не от системы комментирования.
Статистика: Добавлено Mikhail — 27.10.2015 10:27:00
]]>
Разделение делает невозможным полноценное создание АТД либо показывай приватные члены либо делай специальную обертку над неким внутренним классом.
Но ведь protected никто не предлагает отменять
Код:
type
TAbstract = object
protected
procedure DoAbstract; virtual; abstract;
end;
Под АТД такое подразумевается? Такое должно быть разрешено в любом случае.
Проблема документирования надуманная, ИМХО, полно средств ее генерации из комментариев и все равно где именно в модуле она расположена.
Комментарии для таких генераторов, как правило, очень механически написаны, с излишним синтаксисом и т.д. — ухудшают читаемость и кода, и неочевидной информации редко содержат. Как раз нормальные живые комментарии в интерфейсной части о том, как эту интерфейсну часть правильно использовать, лучше всех. Лучше их только отдельно написанная живая документация.
Статистика: Добавлено Дож — 27.10.2015 10:23:14
]]>
Mirage писал(а):Документация часто бывает в виде комментариев как раз к публичной части класса/модуля. Что на мой взгляд наиболее практично и удобно. Причем удобнее всего именно когда она сосредоточена в интерфейсной секции. Так что разделение на секции рано списывать.
Разделение делает невозможным полноценное создание АТД либо показывай приватные члены либо делай специальную обертку над неким внутренним классом.
Проблема документирования надуманная, ИМХО, полно средств ее генерации из комментариев и все равно где именно в модуле она расположена. В больших же проектах такой документации просто недостаточно, необходима дополнительная документация о структуре библиотек (проекта) в целом, интерфейсах взаимодействия компонентов, некоторые общие соображения о принципах построения компонентов системы и т.п. Иначе все это приходится изучать по исходникам и вовсе не по секции интерфейса, что занимает много времени. Кстати, у FreePascal и Lazarus с этим плохо, мало документации именно о структуре компилятора, LCL и т.д.
Mirage писал(а):А усложнение от этого микроскопическое.
Воспринимается это намного сложнее и ошибки будет искать сложнее. А вообще, например, в скроссплатформенном, якобы, модуле SysUtils в интерфейсе цепляется модуль Windows под Win32, Linux, под Linux и т.д.
Статистика: Добавлено Mikhail — 27.10.2015 10:03:11
]]>