Вот завел себе блог

← →
pasha_golub © (2007-03-11 15:02) [120]

> jack128 © (09.03.07 21:16) [98]

> думаю многие хранили Integer в TList"е

Откуда ты узнал? :))

← →
Eraser © (2007-03-11 15:19) [121]

> [117] euru © (11.03.07 02:13)

это всё конечно хорошо, но главное приемущество записи в том, что её можно просто взять и скопировать или сохранить куда-то, без помощи каких-то специальных методов самой записи. Не знаю правда можно ли так поступать с object"ами, но думаю что нет, вряд ли объекты можно плодить простым копированием. А насчет того, где выделяется память - это уже второй вопрос, частенько и под записи (и осоенно массивы заисей) память приходится выделять через GetMem.

← →
oxffff © (2007-03-11 16:02) [122]

> Теперь разработчики добавляют для типов record возможность
> определения в них методов обработки (конъюнктурное решение,
> вызванное, я так понимаю, поддержкой в Delphi технологии
> .Net). Но раз уже использовалась такая возможность в типах
> object, почему бы не перенести всю функциональность object
> на record (раз уж они с таким упорством открещиваются от
> object), сделав record более гибким, чем в C#. А object
> могли бы обозвать синонимом record в целях обратной совместимости.
>

Object мог запутать.
Поскольку к нему можно было применить Typeof для получения VTB.
А виртульные методы в record не объявишь.

← →
oxffff © (2007-03-11 16:07) [123]

> Eraser © (11.03.07 15:19) [121]
> > [117] euru © (11.03.07 02:13)
>
> это всё конечно хорошо, но главное приемущество записи в
> том, что её можно просто взять и скопировать или сохранить
> куда-то, без помощи каких-то специальных методов самой записи.
> Не знаю правда можно ли так поступать с object"ами, но
> думаю что нет, вряд ли объекты можно плодить простым копированием.
> А насчет того, где выделяется память - это уже второй вопрос,
> частенько и под записи (и осоенно массивы заисей) память
> приходится выделять через GetMem.

В system.pas

Compiler magic

procedure _ObjCopy;

Правда по коду явно не глубокое копирование, как прочем и у record.

← →
euru © (2007-03-11 16:36) [124]

> Eraser © (11.03.07 15:19) [121]
> главное приемущество записи в том, что её можно просто взять
> и скопировать или сохранить куда-то, без помощи каких-то
> специальных методов самой записи. Не знаю правда можно ли
> так поступать с object"ами, но думаю что нет, вряд ли объекты
> можно плодить простым копированием.
Как раз object (в отличие от class) можно копировать так же, как и record.

← →
jack128 © (2007-03-11 20:43) [125]

Опс. Пропустил ответ:
Игорь Шевченко © (09.03.07 17:04) [38]
Какие предки и потомки у helper"ов ? Каждый helper является равноправным.

Из хелпа Turbo Delphi
The syntax for declaring a class helper is: type identifierName = class helper [(ancestor list)] for classTypeIdentifierName memberList end; The ancestor list is optional. A class helper type may not declare instance data, but class fields are allowed.

← →
Игорь Шевченко © (2007-03-11 20:49) [126]

jack128 © (11.03.07 20:43) [125]

Во-первых, в твоем коде были равноправные хелперы.
Во-вторых, а не затруднит ли тебя объяснить физический смысл ancestor list в данном определении ?

← →
vuk © (2007-03-11 20:56) [127]

Кстати. Почему они там написали именно "ancestor list" понять трудно. Наверное все-таки, как и у класса, должно быть "ancestorClass" А вот зачем хелперу предок - это понятно. Например, если есть желание расширить существующий хелпер...

← →
Игорь Шевченко © (2007-03-11 21:00) [128]

vuk © (11.03.07 20:56) [127]

> Например, если есть желание расширить существующий хелпер.
> ..

Например каким образом ?

← →
jack128 © (2007-03-11 21:03) [129]

Игорь Шевченко © (11.03.07 20:49) [126]
Во-первых, в твоем коде были равноправные хелперы.
Я потом исправился :-)
vuk © (11.03.07 20:56) [127]
Почему они там написали именно "ancestor list" понять трудно.
Ну например
vuk © (11.03.07 20:56) [127]
если есть желание расширить существующий хелперЫ...
;-)

← →
vuk © (2007-03-11 21:04) [130]

to Игорь Шевченко © (11.03.07 21:00) [128]:
>Например каким образом ?
Издеваисся? :) Унаследовать хелпер от существующего и добавить нужную функциональность.

← →
Игорь Шевченко © (2007-03-11 21:07) [131]

vuk © (11.03.07 21:04) [130]

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

Объясни бестолковому.

← →
vuk © (2007-03-11 21:09) [132]

to jack128 © (11.03.07 21:03) [129]:
>Ну например
>vuk © (11.03.07 20:56) [127]
>если есть желание расширить существующий хелперЫ...
Дак у класса-то только один предок бывает... Хелпер-то, он тоже класс, хоть и специальный.

← →
vuk © (2007-03-11 21:15) [133]

to Игорь Шевченко © (11.03.07 21:07) [131]:
>Если хелпер содержит только набор методов и классовых свойств, нафига
>может потребоваться его расширять ?
Ровно так же как с классами. Ну вот не хватило тебе функциональности в существующем хелпере. Не переписывать же хелпер с нуля только для того, чтобы добавить один-два метода?

← →
jack128 © (2007-03-11 21:21) [134]

vuk © (11.03.07 21:09) [132]
Хелпер-то, он тоже класс, хоть и специальный.
Нет. Он - не класс. Ну ни коем образом не класс. Хелпер - это просто сборник методов и ничего более. Если те нужно объеденить 2 сборника в один - просто объявляешь наследника обоих..

← →
Игорь Шевченко © (2007-03-11 21:24) [135]

vuk © (11.03.07 21:15) [133]

Э...а я разве существующим не смогу воспользоваться ? Зачем переписывать с нуля ?

Или это так же как с наследованием интерфейсов ?

← →
jack128 © (2007-03-11 21:31) [136]

Игорь Шевченко © (11.03.07 21:24) [135]
Э...а я разве существующим не смогу воспользоваться ? Зачем переписывать с нуля ?

Например у тя есть helper для TStrings. Он используется нескольких приложениях, в том числе и в консольных.
Терь те нужно сделать добавить в него метод, но этот метод требует модуля Forms. ТО есть если ты добавить этот метод в уже существующий хелпер, то все твои консольные приложения потянут за собой Forms. Не очень хорошая ситуация, согласись ;-)

Кста, множественное наследование хелперов - не фига не работает :-)

← →
oxffff © (2007-03-11 21:36) [137]

> Кста, множественное наследование хелперов - не фига не работает
> :-)

Приведи код

← →
jack128 © (2007-03-11 21:37) [138]

type TObjectHelper1 = class helper for TObject public procedure Test; end; TObjectHelper2 = class helper for TObject public procedure Test2; end; TObjectHelper3 = class helper (TObjectHelper1, TObjectHelper2) for TObject public procedure Test3; end; procedure TForm9.FormCreate(Sender: TObject); begin end; { TObjectHelper1 } procedure TObjectHelper1.Test; begin ShowMessage("TObjectHelper1.Test"); end; { TObjectHelper2 } procedure TObjectHelper2.Test2; begin ShowMessage("TObjectHelper2.Test"); end; { TObjectHelper3 } procedure TObjectHelper3.Test3; begin ShowMessage("TObjectHelper3.Test"); end; end.

← →
jack128 © (2007-03-11 21:38) [139]

jack128 © (11.03.07 21:37) [138]
TObjectHelper3 = class helper (TObjectHelper1, TObjectHelper2) for TObject
[Pascal Error] Unit9.pas(36): E2029 ")" expected but "," found

← →
vuk © (2007-03-11 21:40) [140]

jack128 © (11.03.07 21:21) [134]:
>Хелпер - это просто сборник методов и ничего более.
Ага, а класс - не сборник. Или вот, например, интерфейс. Это что такое?

>Если те нужно объеденить 2 сборника в один - просто объявляешь
>наследника обоих..
Сам-то пробовал перед тем, как написать? ;)

to Игорь Шевченко © (11.03.07 21:24) [135]:
>Э...а я разве существующим не смогу воспользоваться ?
Ну да, в один конкретный момент доступен только один хелпер - ближайший по видимости. То есть если хотим свой использовать, то другие будут невидимы. Совместить функциональность можно только наследованием.

← →
jack128 © (2007-03-11 21:44) [141]

vuk © (11.03.07 21:40) [140]
Или вот, например, интерфейс. Это что такое?
Интерфейсы - это именно сборники методов. Они, кстати, множественное наследование поддерживают ;-)

← →
Игорь Шевченко © (2007-03-11 21:46) [142]

jack128 © (11.03.07 21:31) [136]

> Например у тя есть helper для TStrings. Он используется
> нескольких приложениях, в том числе и в консольных.
> Терь те нужно сделать добавить в него метод, но этот метод
> требует модуля Forms. ТО есть если ты добавить этот метод
> в уже существующий хелпер, то все твои консольные приложения
> потянут за собой Forms.

Я могу написать несколько helper"ов для одного класса (для того же Tstrings)

Костыль на костыле получается. Suxx

← →
Игорь Шевченко © (2007-03-11 21:48) [143]

vuk © (11.03.07 21:40) [140]

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

А явно имя квалифицировать не получится ?

← →
oxffff © (2007-03-11 21:48) [144]

> >Если те нужно объеденить 2 сборника в один - просто объявляешь
>
> >наследника обоих..
> Сам-то пробовал перед тем, как написать? ;)

Никаких препятствий для этого нет.

Виртуальных методов нет (ну во всяком случае не работают), поля запрещены, классовые поля - не помеха те же глобальные переменные с ограниченным Scope.

Только судя по всему ancestor list - это опечатка .

← →
oxffff © (2007-03-11 21:56) [145]

> А явно имя квалифицировать не получится ?

Не работает.

← →
Игорь Шевченко © (2007-03-11 22:01) [146]

oxffff © (11.03.07 21:56) [145]

> Не работает.

Ну и ладно. Делать надстройку над костылем - ну не понимаю я, нафига это надо, когда есть ясный и понятный механизм наследования.

И кроме того, простые процедуры тоже пока никто не отменял в Delphi для Win32.

← →
oxffff © (2007-03-11 22:06) [147]

> И кроме того, простые процедуры тоже пока никто не отменял
> в Delphi для Win32.

Верно только когда в модуле множество "help" процедур и функций для различных классов. То class helper позволяет группировать их по функциональности. Поэтому с этой точки зрения удобно увидить их в нужном scope объекта.

Но лично я для себя вижу больше плюсов от record help.

← →
oxffff © (2007-03-11 22:11) [148]

Естественно ноги растут из .NET struct c методами и интерфейсами. Только понятно, что в самой области памяти занимаемой структурой нет никаких сслылок аля всех тех которые по отрицательному смещению от VTB.
Да и не нужны они, поскольку нет наследования для структур. Поэтому тип известен на этапе компиляции и однозначно можно вызвать метод или получить интерфейс для этого типа.

И все это плюс. Хотя в плане scope

oxffff © (11.03.07 22:06) [147]

> Верно только когда в модуле множество "help" процедур и
> функций для различных классов. То class helper позволяет
> группировать их по функциональности. Поэтому с этой точки
> зрения удобно увидить их в нужном scope объекта.

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

>
> Ну и ладно. Делать надстройку над костылем - ну не понимаю
> я, нафига это надо, когда есть ясный и понятный механизм
> наследования.

Что касаемо этого, то help очень однозначно определяет область их приминения

Class helpers provide a way to extend a class, but they should not be viewed as a design tool to be used when developing new code. They should be used solely for their intended purpose, which is language and platform RTL binding.

> Дизайн надо пересматривать, а не костыли городить. Фаулера
> читать.

Ответ в [150]

oxffff © (11.03.07 22:14) [150]

Я читать умею, спасибо. И еще раз могу сказать, что для сопряжения System.Object из .Net Framework и TObject без особой потери совместимости со старым кодом helper"ы вполне уместно использовать, что в Borland и сделали. Но больше причины для их применения я не вижу. Даже в старом коде.

Книги нужно читать и всегда думать.

Например Гамма, Хелм, Джонсон, Влисидесс
Тот же Буч
тот же Ларман
используют в качестве примеров C++.

Но заверяю вас, да и вы сами знаете.
В delphi есть языковые средства которые позволяют решить проблему проще и элегантнее.

Могу сказать, книги пора уже самим писать. :)

> Даже в старом коде.

В своем безусловно.

А чужом, который нельзя модифицировать?

oxffff © (11.03.07 22:19) [153]

> В delphi есть языковые средства которые позволяют решить
> проблему проще и элегантнее.

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

oxffff © (11.03.07 22:22) [154]

> А чужом, который нельзя модифицировать?

И что ? Никто не запрещает наследоваться от классов в чужом коде, никто не запрещает писать процедуры вокруг классов чужого кода.
Главное, что объявив процедуру со своим именем, ты делаешь очевидным тот факт, что используется твое собственное расширение чужого кода, а написав helper и вызывая его метод у объекта, ты вносишь путаницу, потому что противоречишь интерфейсу чужого класса.

to jack128 © (11.03.07 21:44) [141]:
>Они, кстати, множественное наследование поддерживают ;-)
И давно? Нет, про множественную реализацию, это я в курсе. Но это не наследование и оно не у интерфейсов, а у классов.

← →
ТЮзер (в нете через паяльник) (2007-03-11 23:13) [157]

Читаю, читаю, .... Кто-нибудь может привести примитивный пример, что такое эти хелперы, и где они удобны? У меня семерка.

> И что ? Никто не запрещает наследоваться от классов в чужом
> коде

Хорошо. Предположим. Мне нужно особую функциональность для объекта опеределенного типа стороннего разработчика.

Я определяю класс наследник. И привожу объект к наследнику. О чем я писал выше.

oxffff © (09.03.07 18:18) [73]
oxffff © (10.03.07 00:35) [104]

Да это решение. Но к сожалению нет способа запретить определение virtual, dynamic(message) методов. Да и привидение будет не безопасным.
Здесь сам разработчик берет на себя эти гарантии.
Другой после этого может и нарушить binary compatibility определив несколько виртуальных или динамических процедур у наследника.
Далее при приведнии будет не понятно.
Почему function ClassType: TClass; возвращает TBaseType вместо дочернего.

В этом решении тоже очень много невыразительности и противоречивости.
Но как костыль тоже подойдет.

> никто не запрещает писать процедуры вокруг классов чужого
> кода.

Классов может быть много и процедур тоже.
А вот иметь общий scope это удобно.

oxffff © (11.03.07 23:17) [158]

> Классов может быть много и процедур тоже.
> А вот иметь общий scope это удобно.

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

С чего началась дискуссия - с вызова Memo.Lines.DoWork. Я смотрю в help - у TStrings нету метода DoWork. Впадаю в ступор.

← →
ТЮзер (в нете через паяльник) (2007-03-11 23:26) [160]

А у хелпера есть DoWork? Или что-то еще там есть?

Вот завел себе блог Найти похожие ветки