» Вопросы по Embarcadero RAD Studio XE4

AlekXL

Цитата:

Я использую интерфейсы в том числе и для того, чтобы ослабить связь между частями проекта

Я разве сказал, что единственное назначение интерфейсов являть собою механизм автоматического управления жизнью объекта? Нет, я сказал о другом.


Цитата:

управляемого не тобой, не так ли?

Отчего же - ты имеешь доступ к счетчику ссылок, можешь им рулить как вздумается. Компилятор просто автоматизирует это, в отличии от GC управляемых сред. То же самое мы имеем с интерфейсами, строками и дин.массивами.


Цитата:

Впрочем концепцию strong vs weak link я бы не назвал простой, тем более что weak link, как я понял, может указывать на что попало. Так что будут и залоченные в памяти взаимно ссылающиеся объекты, и попытки дерефенса освобожденной памяти.

Я ничего сложного в концепции ссылок не вижу, и они уж точно не призваны решать проблемы кривых рук.


Цитата:

А если нужно запихнуть ссылку на объект в Pointer или NativeInt? Такая магия бывает необходима, скажем, для WinApi, или TVirtualDrawTree. Логика работы ARC в этом случае может быть еще сложнее, чем в обычном случае: сначала нужно сделать явный инкремент, а потом всюду следить,чтобы нигде не произошел неявный декремент

Как ты там говорил... Изволь соответствовать? Так вот разговоры о неявном декременте меня удивляют.


Цитата:

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

Пока, вроде, и получается полная обратная совместимость, за исключением случаев взаимных ссылок объектов. А если везде расставить атрибут [weak] будет совсем полная Хотя, я согласен, что такие радикальные изменения должны быть по меньшей мере отключаемыми.

Добавлено:
HeMet

Цитата:

"не используйте это в своем коде - оно не для вас" (вольный перевод: "Class and record helpers provide a way to extend a type, but they should not be viewed as a design tool to be used when developing new code."),

Это слишком уж вольный перевод Оно вообще о другом.


Цитата:

А разрабам Delphi потом тяни лямку

То есть это нормально, когда языковая фича описывается в доке, но нихрена не работает как должна, судя по той же доке?

Про ЭМРО, Qt и LGPL, мое имхо.

Во-первых, мне не ясно как бы они дружили Дельфи с C++ фреймворком. Возможности прозрачно расширять классы фреймворка не будет, если не сделать полную совместимость с объектной моделью C++, а ее сделать сложно (множественное наследование?). Был бы такой же слабый interop как у XE4 c iOS: все вижу, на сделать ничего толком не могу, или сложно сделать. То есть, динамическое линкование forever! В этом смысле FMX был все таки native pascal, с ним из паскаля работать на порядки удобнее: родная классовая модель, прозрачное расширение классов, легкая передача объектов туда-сюда, нет заморочек с менеджерами памяти!

Во-вторых, Qt всегда бы осталась публичной, не было бы контроля над кодом, он не был бы собственностью ЭМРО. А у FMX был плюс, что его можно было купить!

П.С. Я не вижу никаких лицензионных проблем в использовании LGPL фреймворка с коммерческим софтом, но вот все изменения во фреймворке прийдется также делать открыто и под LGPL.

Цитата:

Это слишком уж вольный перевод Оно вообще о другом.

Предназначены для расширения типов, но не должны рассматриваться, как средство проектирование новой архитектуры.
Судя по исходникам ЭМБ решила им следующие проблемы: расширение VCL без полной его переделки, вспомогательный функционал для некоторых записей и методы для простых типов, чтобы они косили под объекты. Т.е. малой кровью лечили недостатки своей долгоживущей кодовой базы. Вероятно, с рассчетом на краткосрочную или среднесрочную перспективу, пока в языке не появятся более адекватные средства. Мне так кажется.

deks

Цитата:

Во-первых, мне не ясно как бы они дружили Дельфи с C++ фреймворком

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


Цитата:

А у FMX был плюс, что его можно было купить!

И в результате не оставить камня на камня от старого кода

HeMet

Цитата:

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

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


Цитата:

Судя по исходникам ЭМБ решила им следующие проблемы: расширение VCL без полной его переделки

Когда они появились - ни в RTL ни в VCL не использовались вообще.

HeMet

Цитата:

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

Да! Я могу все что хочу, и хочу все что могу!
Я хочу использовать old objects, индексировать массивы при помощи (. .)

Код:
vector(.ix.):=1//ВОТ ТАК!

deks
HeMet
valgreesh
AlekXL
и другие.

Блин! Как интересно Вас читать!
Я серьезно.

Цитата:

Судя по исходникам ЭМБ решила им следующие проблемы: расширение VCL без полной его переделки

в этом есть проблема: это костыли. В следующий раз придется расширять не только библиотеку, но и костыли. хелперы для хелперов ?


Цитата:

как трудно выловить баги, связанные с двойным освобождением памяти?    

что именно трудно ? найти где и почему уничтожился в первый раз? но это уже кривихна архитектуры, кто владелец в какой момент времени. Хотя от этого не легче...


Цитата:

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

ты про RAII типа монопольного tfilestream ? для этого они ввели финалайзер - .DisposeOf

Хотя я согласен, что если им нжен был ARC, чем корёжить сущиствующий RTL надо было построить параллельный на TInterfacedObject...


Цитата:

все изменения во фреймворке прийдется также делать открыто и под LGPL.

т.е. проблема только в менталитете начальников ЭМБы.


Цитата:

мне не ясно как бы они дружили Дельфи с C++ фреймворком

Не Qt'ом единым.


Цитата:

тем более что weak link, как я понял, может указывать на что попало

Нет, они обнуляются автоматически, как в ObjC ARC

Что тоже доставит много радости ламерам, любящим писать простыни

DataModule1.Query10.FieldByName('asaas').DataKind := ...
DataModule1.Query10.FieldByName('asaas').DisplayName := ...
DataModule1.Query10.FieldByName('asaas').OnGetText := ...

И когда в середине этакой фигни Query10 "внезапно" станет Nil будет смешно

AlekXL

Цитата:

Придут кодеры, покалеченные Доднедом, и начнут говнокодить

А придут ли...


Цитата:

Ты вообще в курсе, как в нетривиальном коде все может обстоять? Мы не университетской аудитории, это wild-wild-world, там такая может быть "грязная" арифметика указателей, что только держись

Если под "грязной арифметикой" не подразумевать говнокод вида:

Код:
obj := TObject.create;
nativeInt(obj) := 0;

Цитата:

Я хочу использовать old objects, индексировать массивы при помощи (. .)

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


Цитата:

использовать наследование record helper, поля automated и диспетчирезацию методов по dispId.

With тройной вложенности и absolute вместо приведения типа, прямое обращение к портам ввода-вывода и обработка прерываний в прикладном коде. Динамическая диспетчеризация под COM затачивалась, пусть там и остается.


Цитата:

Потому что это мое наследие, наследие всех,

Может мне тоже вспомнить про моё TP-«наследие» со школьной скамьи? Вообще, это называется древний, дремучий код, но «наследие» определённо звучит красивее.


Цитата:

кто однажды полюбил TP или Delphi.

Любите дальше: ставьте DOS на виртуалку, туда TP и ностальгируйте сколько угодно, а в современном языке таких выкрутасов не надо.


Цитата:

Когда я слышу это, мне хочется кого-нибудь убить.

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


Цитата:

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

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


Цитата:

Immutable strings

Нету их ещё и не будет, пока не будет доказана их исключительная полезность. Даже под iOS это COW-строки. То ли народ ничего не читает, то ли у ЭМРО талант свои намерения подавать самым поганым образом.


Цитата:

ARC - причем принудительно.

Он на iOS везде. Ругать iOS-ный компилятор за то, что там везде ARC. Это всё равно, что ругать виндовый за то, что у него весь COM на интерфейсах.


Цитата:

А что будет сломана совместимость с кодом, написанным десять лет назад - что им до того?

Они его как раз вводят таким образом, что бы старый код работал без видимых отличий и переписываний. Разница проявится в особых случаях: например, когда убивается объект, на который есть ссылки из других частей программы.
Под десктопам это приводит к висячим-указателям (dangling pointer), когда не понятно жив пациент или уже нет. А там и двойное высвобождение памяти подоспевает или использование мертвого объекта, короче говоря, бомбы замедленного действия.
В случае ARC объект просто будет жить до тех пор пока на него не пропадут ссылки, либо до конца программы. Если ссылка была на какой-нить файл или типа того, это плохо, но код, который до этого довел, в любом случае, хуже.
Проблемы висячих указателей с ARC тоже нет: свойство Disposed однозначно указывает на состояние объекта.


Цитата:

Это поколение ушибленное додНЕТ.

Не путайте, в .NET сборщик мусора (недерминированный механизм), а ARC - это, по сути, то, что сейчас используется для интерфейсов, динамических массивов и строк.


Цитата:

А что, мордой салат в корпоративах?

Пусть лучше среду развивают, а не древности стерегут.


Цитата:

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

Вы того же самое могли получить, скопировав себе файлы в папку проекта и поправив там, что нужно. Правда, правки были бы не отделимы от остального кода. С другой стороны у хелперов есть неслабый минус: нельзя просто так перекрыть непубличный метод - нужно ещё и перекрыть публичные, которые к нему ведут. Я на это напоролся, когда правил TPathData из FMX: пришлось в хелпер пихать то, что совсем туда пихать не хотелось. В итоге сделал, как написал выше.


Цитата:

Придут кодеры, покалеченные Доднедом, и начнут говнокодить...

И чем их говнокод хуже говнокода с old objects, absolute вложенными with и прочим? Тем что он не «родной»?


Цитата:

Ты вообще в курсе, как в нетривиальном коде все может обстоять? Мы не университетской аудитории, это wild-wild-world, там такая может быть "грязная" арифметика указателей, что только держись.

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


Цитата:

Ты в курсе, еще раз спрошу, как трудно выловить баги, связанные с двойным освобождением памяти?

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


Цитата:

А [weak] следует пристрелить просто за использование скобок, чертова безвкусица.

Он — атрибут, они все в скобках. Но лучше бы сделали ключевым словом.


Цитата:

И я дожен везде его расставлять?

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


Цитата:

В ж""у это уродство!

Вы и так полно уродства описали, чем Вас это так напрягло?


Цитата:

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

Только если в ней ссылки на конкретный объект расползаются чёрт знает куда.
Тут два варианта:
1. Объект всем нужен - ARC сохранит его до тех пор пока он кому-то нужен, а потом замочит.
2. Анти-шаблон «Плюшкин»: хватаем всё что мимо пробегает и ни за что не отпускаем. Косяк в архитектуре: используем слабые ссылки. Без ARC это бы привело либо к утечкам памяти, либо к висячим указателям и двойной очистке памяти.


Цитата:

Так что [weak] практически бесполезен для идеологии ARC

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


Цитата:

либо нужно явно контролировать время жизни самого указателя.

Что ARC и делает, когда обнуляет слабые ссылки на очередной убитый объект.


Цитата:

Да! Я могу все что хочу, и хочу все что могу!  

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

Цитата:

absolute вместо приведения типа

а есть в Дельфи хоть один другой метод приведения типов, удовлетворяющий DRY, т.е. не дублирующий ни приведение ни - временные переменные - значение ?

if x is Txxx then (x as Txxx).dddd - за каким хреном тут as нужен? что за идиотизм?

Приведение типов в Дельфи непрактичное.

Добавлено:

Цитата:

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

тем хуже. тем больше лукавства в якобы одной Delphi для десктопа и мобильных платформ.

Добавлено:

Цитата:

Так оно же и так практически эквивалентно.

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

надо изначално было ввести [weak] в TInterfacedObject и танцевать ARC от него, а не перекраивать базовую модель TObject

Цитата:

if x is Txxx then (x as Txxx).dddd - за каким хреном тут as нужен? что за идиотизм?

а так
if x is Txxx then Txxx(x).dddd

и то и другое одинаково нарушают DRY

второе к тому же опаснее для будущей возможной переделки типов или для копипаста с другими классами, если строится лесенка типа

if t is Txxxx then...
if t is Tyyyy then...
if t is Tzzzz then Txxxx(t).ddddd

Цитата:

и то и другое одинаково нарушают DRY

А как надо?

у absolute есть на мой вкус два недостатка.

1) это вообще не там объявляется. Это должно быть не в типе, а в переменной. Как в других паскалях

Код: var XXX origin YYY: TTTT;

Arioch1

Цитата:

тем больше лукавства в якобы одной Delphi для десктопа и мобильных платформ

Для прикладного кода разница и правда невелика.


Цитата:

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

Совсем даже не одинаковые - TInterfacedObject реализует IInterface.


Цитата:

if x is Txxx then (x as Txxx).dddd - за каким хреном тут as нужен? что за идиотизм?

А он тут и не нужен. As нужен там где отсутствует проверка типа.

Arioch1
HeMet
Без absolute обойтись можно всегда, но эта конструкция избавляет от кода вроде:
Код: TOtherType((@VarOfAnyType)^)

Arioch1

Цитата:

if x is Txxx then (x as Txxx).dddd - за каким хреном тут as нужен? что за идиотизм?

Что, в других языках софткаст к типу не нужен? ... Интересно.

Добавлено:

Цитата:

у absolute есть на мой вкус два недостатка.

Absolute - это наложение, а не каст. Не там объявляется? Какая ещё проверка как у as при наложении? .. мда, отборный бред ...

К чему вся эта каша из головы? Опять народу мозги пудрим?

Цитата:

Что, в других языках софткаст

Component Pascal: if var is type - уже софткаст.


Цитата:

Absolute - это наложение, а не каст.

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

Arioch1

Цитата:

Component Pascal: if var is type - уже софткаст.

...


Цитата:

И иногда это мешает им пользоваться.

Примеры в студию или личку


Цитата:

тайпкаст, централизованный в начале функции как absolute

Не ясно что имеется ввиду вообще. Разговор за begin инициализатор в методе чтоли?

Очередной раз про "удачный" RTL Дельфи.

Ну, коллеги - хоть кто то может мне сказать, почему у классов из System.Generics.Collections (например, TObjectList <T>) все методы - не виртуальные?! То есть я не могу их переопределить, чтобы добавить нужное мне поведение! Ну вот какая логика-то в этом была, когда это делали?

Цитата:

... а есть в Дельфи хоть один другой метод приведения типов, удовлетворяющий DRY, т.е. не дублирующий ни приведение ни - временные переменные - значение ?
if x is Txxx then (x as Txxx).dddd - за каким хреном тут as нужен? что за идиотизм? ...

Цитата:

... а так if x is Txxx then Txxx(x).dddd ...

Цитата:

... и то и другое одинаково нарушают DRY ...

Вобщем задался вопросом и правда, а как ???
Решение, которое нашел, конечно далеко не идеальное, но от ошибок избавляет:

Обобщенный тип:

Код:
type

TCast<T: class> = record
class function Check(Src: TObject; out Dst: T): Boolean; static; inline;
end;

....

class function TCast<T>.Check(Src: TObject; out Dst: T): boolean;
begin
Result := Src is T;
if Result then
TObject(Dst) := Src;
end;

RuXandr
А так быстрее и меньше памяти жрёт:

Код:
procedure TForm1.Button1Click(Sender: TObject);
var
btn: TButton absolute Sender;
begin
if Sender is TButton then
btn.Caption := 'ok';
end;

Цитата:

Ну, коллеги - хоть кто то может мне сказать, почему у классов из System.Generics.Collections (например, TObjectList <T>) все методы - не виртуальные?! То есть я не могу их переопределить, чтобы добавить нужное мне поведение! Ну вот какая логика-то в этом была, когда это делали?

аллах с ними. Есть куда более мощные библиотеки контейнеров. Как есть и для шарпа C5 либа.
у меня новая заморочка

Код:
readSuccess:=ReadFileEx(Handle,Addr(Buffer),count,Addr(request.Overlapped),@FileIOCompletionRoutine );
//readFileEx result is quite meaningless
err:=GetLastError();
//if readSuccess==true, then operation completed synchronously
Inc(tries);
readSuccess:= (err=ERROR_SUCCESS) or (err=ERROR_IO_PENDING) or (err=ERROR_IO_INCOMPLETE);

AlekXL

Цитата:

TRequest = class(TMyInterfacedObject,IovRequestWin)

Цитата:

мне нужно вернуть TRequest в качестве IovRequest. Присваивание не работает, внезапно. Код

Оно правильно не работает. Чтоб работало (хоть присваивание, хоть запрос), поддержку интерфейса классом нужно декларировать явно:


Код: TRequest = class(TMyInterfacedObject, IovRequest, IovRequestWin)

Цитата:

Ну, коллеги - хоть кто то может мне сказать, почему у классов из System.Generics.Collections (например, TObjectList <T>) все методы - не виртуальные?! То есть я не могу их переопределить, чтобы добавить нужное мне поведение!

Ты бредишь.

Код: TCollectionNotification = (cnAdded, cnRemoved, cnExtracted);

TObjectList<T: class> = class(TList<T>)
...
protected
procedure Notify(const Value: T; Action: TCollectionNotification); override;

ego666
Цитата:

и странно, что на самом MSDN об этом не говорится

MSDN-библиотечку уже не раз неслабо перелопатили, частенько с потерей информации. [more=Лирическое отступление про наболевшее с LCIDами]Ну вот чем им мешала таблица с короткой строковой записью локалей? Снесли, сослались на другое место, типа таблица теперь там, только в ней столбца "Short string" нет и ID только в десятичной системе. Потыркавшись кое-как удаётся найти некое Appendix A от [MS-LCID]: Windows Language Code Identifier (LCID) Reference. Правда таблица в нём ооочень полная, охватывающая всё и вся, и с буквенными кодами, но числовые в ней - уже в hex. Ну жалко им что ли было рядом ещё и для dec-значений столбец выделить, не понимаю... Здесь так, там эдак [/more]. Поэтому удобнее и полезнее бывает пользоваться ещё и актикварной документацией, даже времён Win98.

Но в данном случае они не совсем кастрировали старый текст, просто вынесли эти подробности в отдельную статью:
Цитата:

There are strict requirements for successfully working with files opened with CreateFile using FILE_FLAG_NO_BUFFERING. For details see File Buffering.

PS: Соковиков, кстати, про свой перевод на главной говорит, что
Цитата:

основой для переведенных статей, описания функций, макрокоманд, сообщений, уведомлений и структур и т. д. стал выпуск Библиотеки MSDN от января 2005 и 2008 года, а не справка к какому либо компилятору

Ещё та MSDN Library, которую можно было скачать в виде .iso-шек

ego666


Цитата:

Ты бредишь.

Ну - будем говорить про отличие в ПЕРЕОПРЕДЕЛЕНИИ методов и получение уведомлений о действиях? Как вы через нотификацию сможете переопределить TList.Count, например, для реализации LazyLoad списка файлов/папок по доступу к Count? Внимательнее))

deks
Если хочется странного, то нужно писать собственный класс списка, удовлетворяющий требованиям. Стандартный TList удобен и прост и его возможностей вполне хватает для большинства обычных задач и не нужно его уродовать.

P.S.
А проперти в наследниках можно перекрывать, собственно так раньше без дженериков и делали.

ego666

Спасибо, КЭП. То есть отличие между нотификациями и наследованием мы уже поняли. Хорошо.

А теперь - что ж странного то в желании задействовать стандартный список для управления списоком файлов и папок? На мой взгляд - странно как раз то, что этого сделать нельзя. В Java/ObjC можно. А в Дельфи приходится делать свой велосипед. При этом, велосипед не будет совместим со стандратным списком (там, где используется стандартный список - его использовать будет нельзя).

Чем "изуродует" стандартный TList добавление ко всем методам слова virtual я не понимаю.

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

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



Добавлено:
Eternal_Shield
RuXandr

В Oxygene обнаружилась для похожих вариантов две конструкции, которые генерируют безопасный код. Зацените:


Код: with matching obj := TButton(Sender) do obj.Caption := 'ok';

deks
ещё раз, хочешь странного - пиши сам или бери готовое (коллекции от Ciobanu Alexandru, там и как в джаве и как шарпе). Мне и 99% программистам в 99% случаев вполне хватает стандартных списков.


Цитата:

Чем "изуродует" стандартный TList добавление ко всем методам слова virtual я не понимаю.

одними приписками не обойдёшься, TList хранит элементы тупо в массиве, нужно будет всё менять.

Добавлено:

Цитата:

Оно правильно не работает. Чтоб работало (хоть присваивание, хоть запрос), поддержку интерфейса классом нужно декларировать явно

Заранее поясню, так делать обязывает COM. Что кстати даёт Делфи дополнительные плюшки, перед другими языками (джава, шарп вроде тоже, с++ (ну у него вообще их нет)), где у интерфейсов наследование такое же как и у классов.

ego666

Цитата:

хочешь странного

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


Цитата:

Мне и 99% программистам

Не нужно творческих обобщений. Вам хватает - ок, не спорю, наверное хватает)) Мне нет, и я не понимаю причин такой нелепой убогости такой архитектуры! Если бы в дельфи стандартных коллекций хватало 99% программистов, не было бы кучи сторонних библиотек с контейнерами - DeHL, Collections, Spring, etc.


Цитата:

одними приписками не обойдёшься, TList хранит элементы тупо в массиве, нужно будет всё менять

Exactly! При виртуальных методах можно полностью заменить схему хранения, оставляя такой же "наружный" интерфейс. Именно для подобных вещей и нужны виртуальные методы: кастомизация!

AlekXL
valgreesh

Цитата:

Оно правильно не работает.

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

A заморочка скорее всего с типом переменной-ссылкой на объект. Вместо классового типа, нужно использовать интерфейсные переменные (не TRequest, а IRequest) для получения доступа к методам интерфейса. Хз. ЛУчше привести полный код - так будет понятнее.