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

← →
Игорь Шевченко © (2007-03-09 17:06) [40]

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

← →
jack128 © (2007-03-09 17:06) [41]

Суслик © (09.03.07 17:00) [34]
правило простое - используется 0 или 1 хелпер, который ближе по скопу.

БЛИН!!!! Я облажался, когда пример писал.

Хелпер-потомок, добавляет overload метод
unit Unit4; interface uses Classes, Unit3; type TStringsHelper = class helper (Unit3.TStringsHelper) for TStrings public procedure DoWork(I: Integer); overload; end; implementation procedure TStringsHelper.DoWork(I: Integer); begin // end; end.

То есть потомок скрывает метод предка, хотя в потомке метолдж объявлен как overload

← →
jack128 © (2007-03-09 17:07) [42]

Игорь Шевченко © (09.03.07 17:06) [40]
Кстати, пониманию исходного кода эти хелперы не способствуют, а вредят.
почему?

← →
Суслик © (2007-03-09 17:07) [43]

> [38] Игорь Шевченко © (09.03.07 17:04)

вообще-то хелперы и наследовать можно

← →
Суслик © (2007-03-09 17:08) [44]

> [42] jack128 © (09.03.07 17:07)
> Игорь Шевченко © (09.03.07 17:06) [40]
> Кстати, пониманию исходного кода эти хелперы не способствуют,
> а вредят.
> почему?

Игорь из партии консерваторов :)

Хотя я скорее соглашусь с ним - использовать данную конструкцию на регулярной основе не нужно. Только как исключительный случай.

← →
Суслик © (2007-03-09 17:09) [45]

> [39] oxffff © (09.03.07 17:04)
> Есть еще вариант
>
> TXmlNodeAdapter=class
> public
> construcor create(Node:TXmlNode);
> end;

и что с этим делать дальше?

← →
oxffff © (2007-03-09 17:12) [46]

TXmlNodeAdapter=class
> public
> construcor create(Node:TXmlNode);
> end;

Тот же самый Адаптер, который транслирует удобные вызовы в неудобные.

← →
jack128 © (2007-03-09 17:12) [47]

Суслик © (09.03.07 17:08) [44]
Только как исключительный случай.
приведенный вариант со стримами - это исключительный случай?

← →
Джо © (2007-03-09 17:16) [48]

Касаемо моего примера со стримом, меня остановило след. соображение.
Безусловно, написание кода это облегчает. Но вот облегчает ли это его чтение посторонним человеком? Подумал, что, скорее всего, только затруднит. Ибо ход мысли такой: «Какой-такой метод у TStream (а в параметрах метода именно и передается тип TStream)? Нету такого. Гм». А хелперы — относительно новая синт. конструкция, далеко не все ее знают. И выходит путаницы.
В таком роде :)

← →
oxffff © (2007-03-09 17:17) [49]

> oxffff © (09.03.07 17:12) [46]
> TXmlNodeAdapter=class
> > public
> > construcor create(Node:TXmlNode);
> > end;
>
> Тот же самый Адаптер, который транслирует удобные вызовы
> в неудобные.

Кстати ты может привести TXmlNode к TXmlNodeEx.
А в TXmlNodeEx дописать твои удобные методы.
И helper не будет нужен вовсе.

← →
Игорь Шевченко © (2007-03-09 17:17) [50]

jack128 © (09.03.07 17:07) [42]

> почему?

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

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

Суслик © (09.03.07 17:07) [43]

> вообще-то хелперы и наследовать можно

В исходном коде этого не было :)

← →
oxffff © (2007-03-09 17:19) [51]

> Потому что любую хорошую идею умудряются извратить до такого
> состояния, когда вместо того, чтобы упрощать код, она выполняет
> прямо противоположную функцию.

+118.

Долой helperы

← →
jack128 © (2007-03-09 17:21) [52]

Джо © (09.03.07 17:16) [48]
А хелперы — относительно новая синт. конструкция
То есть через 3 года, когда эта конструкция станет старой, ты перешишь свой код на хелперы? Бред.

А Ctrl+Click - приведет тебя к реализации хелпера, откуда и можно все узнать.

← →
Джо © (2007-03-09 17:23) [53]

> [52] jack128 © (09.03.07 17:21)
> Джо © (09.03.07 17:16) [48]
> А хелперы — относительно новая синт. конструкция
> То есть через 3 года, когда эта конструкция станет старой,
> ты перешишь свой код на хелперы? Бред.

Да не стану я его переписывать. Он и так работает, зачем я буду его трогать?
А новый, возможно, напишу и с хелперами. Не знаю. Я же сказал, что окончательно не определился. Может, эта ветка подкинет мне новую пищу для размышлений. :)

← →
Суслик © (2007-03-09 17:23) [54]

вообще-то code insight показывает методы хелперов

← →
jack128 © (2007-03-09 17:25) [55]

Игорь Шевченко © (09.03.07 17:17) [50]
Потому что любую хорошую идею умудряются извратить до такого состояния, когда вместо того, чтобы упрощать код, она выполняет прямо противоположную функцию.

oxffff © (09.03.07 17:19) [51]
+118.

Долой helperы

Действительно. Например идею ООП.

ДОЛОЙ ООП!!!!!!!!!!! ООП - маст дай!!!!!!!!!!!!

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

← →
Игорь Шевченко © (2007-03-09 17:25) [56]

Кстати, обычно качественным источником примеров являются файлы, поставляемые вместе c Delphi. В 2006 единственным местом, где используется эта синтаксическая конструкция, является Indy при компиляции под .Net.

Более того, под .Net эти helper"ы вполне оправданы, так как модифицировать CLI вряд ли кто-то в здравом уме решится.

jack128 © (09.03.07 17:21) [52]

> А Ctrl+Click - приведет тебя к реализации хелпера, откуда
> и можно все узнать.

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

← →
GrayFace © (2007-03-09 17:27) [57]

Игорь Шевченко © (09.03.07 17:04) [38]
"You can define and associate multiple class helpers with a single class type. However, only zero or one class helper applies in any specific location in source code. The class helper defined in the nearest scope will apply"
Эх, такую хорошую вещь кастрировали.

← →
Игорь Шевченко © (2007-03-09 17:31) [58]

jack128 © (09.03.07 17:25) [55]

> А вообще - если человек не в состоянии грамотно использовать
> такую весьма простую концепцию, как хелперы, уж о том, что
> он сможет нормально использовать/реализовывать классы и
> объекты - можно забыть.

Точно. И шаблоны с множественным наследованием и макросами. Таких надо просто отстреливать, чтобы не мешали.

← →
jack128 © (2007-03-09 17:32) [59]

Игорь Шевченко © (09.03.07 17:25) [56]
А за такие советы, Женя, давить надо, потому что исходный код читается не только в среде.
Племя, блин, младое, незнакомое.

Читать хелперы вне IDE - не намного сложнее, чем иерархию классов. Что в первом, что во втором случае - ты должен перерыть все модули, подключеные через uses

← →
Джо © (2007-03-09 17:32) [60]

Эх, застрелите меня уже в конце концов. Что-то народ и вправду после праздника какой-то агрессивный :(

← →
Суслик © (2007-03-09 17:33) [61]

> [60] Джо © (09.03.07 17:32)
> Эх, застрелите меня уже в конце концов. Что-то народ и вправду
> после праздника какой-то агрессивный :(

ты это к чему?
что случилось?

← →
oxffff © (2007-03-09 17:33) [62]

> Долой helperы
>
> Действительно. Например идею ООП.
>
> ДОЛОЙ ООП!!!!!!!!!!! ООП - маст дай!!!!!!!!!!!!
>
> А вообще - если человек не в состоянии грамотно использовать
> такую весьма простую концепцию, как хелперы, уж о том, что
> он сможет нормально использовать/реализовывать классы и
> объекты - можно забыть.

Стоп.
Посмотри oxffff © (09.03.07 17:17) [49]

Единственная проблема в [49], что здесь привидение типов Not type safe.
Вот здесь и заключается приимущество helperа.

Но стоит вводить helper из-за этого.

← →
GrayFace © (2007-03-09 17:35) [63]

Игорь Шевченко © (09.03.07 17:25) [56]
А за такие советы, Женя, давить надо, потому что исходный код читается не только в среде.
Эта такая редкая ситуация, что на нее нет смысла обращать внимание.

← →
Игорь Шевченко © (2007-03-09 17:36) [64]

jack128 © (09.03.07 17:32) [59]

> Читать хелперы вне IDE - не намного сложнее, чем иерархию
> классов. Что в первом, что во втором случае - ты должен
> перерыть все модули, подключеные через uses

Тебе самому не смешно ? Мне уже.

Читать и думать над прочитанным.

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают
создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой
подход может обернуться неприятностями, если программисты реализуют простые
вещи сложными способами, просто потому что им известны эти способы и они умеют
ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной
иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне
затрудняется их просмотр и анализ ментальной модели, которую по существу
реализует код. Всецело нарушаются правила простоты, ясности и прозрачности,
а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы
при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения
правила представления. С этой точки зрения множество классов приравнивается
к внедрению знаний в данные. Проблема данного подхода заключается в том, что
слишком часто "развитые данные" в связующих уровнях фактически не относятся
у какому-либо естественному объекту в области действия программы -
они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них
предметных областей (GUI-интерфейсы, моделирование, графические средства),
возможно, является то, что в этих областях относительно трудно неправильно
определить онтологию типов. Например, в GUI-интерфейсах и графических средствах
присутствует довольно естественное соотвествие между манипулируемыми
визуальными объектами и классами. Если выясняется, что создается большое
количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень стал слишком большим."

← →
Игорь Шевченко © (2007-03-09 17:36) [65]

GrayFace © (09.03.07 17:35) [63]

> Эта такая редкая ситуация, что на нее нет смысла обращать
> внимание.

Ошибаешься

← →
oxffff © (2007-03-09 17:41) [66]

> Игорь Шевченко © (09.03.07 17:31) [58]
> jack128 © (09.03.07 17:25) [55]
>
>
> > А вообще - если человек не в состоянии грамотно использовать
>
> > такую весьма простую концепцию, как хелперы, уж о том,
> что
> > он сможет нормально использовать/реализовывать классы
> и
> > объекты - можно забыть.
>
>
> Точно. И шаблоны с множественным наследованием и макросами.
> Таких надо просто отстреливать, чтобы не мешали.

Зачем. Человеку нужно время.

to jack128

Почитай внимательно

A class helper type may not declare instance data, but class fields are allowed.

Т.Е. на уровня instanceSize никаких изменений, только методы.
+ Возможно Helper VTB, но которая передается как параметр. (кстати еще не реализовано).

Ну и есть ли смысл. В том чтобы вводить helper, вместо того чтобы написать

так либо adapter oxffff © (09.03.07 17:12) [46]

либо non type safe

ClassA=class

end;
classB=Class(ClassA)

end;

var b:ClassB;

b:=ClassB(ClassA.create);

Делов то.

← →
jack128 © (2007-03-09 18:03) [67]

oxffff © (09.03.07 17:33) [62]
Вот здесь и заключается приимущество helperа.
Но стоит вводить helper из-за этого.
oxffff © (09.03.07 17:41) [66]
Делов то.
угу. Вы не находите, что предлагаете ПОЛНЫЙ аналог хелперов, но этот аналог обильно присыпан граблями?

Игорь Шевченко © (09.03.07 17:36) [64]
Читать и думать над прочитанным.
И? Два уровня иерархии - это много? А без IDE и в двух уровнях рахобраться не просто.

← →
Игорь Шевченко © (2007-03-09 18:08) [68]

jack128 © (09.03.07 18:03) [67]

> А без IDE и в двух уровнях рахобраться не просто.

Бедные программисты. Без IDE уже никуда. Вот смотри, Женя, есть двольно крупные проекты (операционная система - очень крупный проект_ написанные совершенно без ООП и в то же время абсолютно понятны и относительно легко модифицируемые (для крупных проектов понятие легкости модификации вообще под сомнением) - это Windows и Linux. Могу еще для примера привести СУБД Oracle - тоже на чистом С, без какого либо ООП - и ничего, живут себе, развиваются, дай Аллах каждому проекту столько времени жизни без переписывания набело.

Значит, не такая серебряная пуля это ООП, модульность гораздо важнее, не правда ли ?

> угу. Вы не находите, что предлагаете ПОЛНЫЙ аналог хелперов,
> но этот аналог обильно присыпан граблями?

Продемострируйте грабли

> Суслик © (09.03.07 18:12) [71]
> Ну это же уже хамство какое-то :)

Нет. Просто... "Когда слепой ведет слепого..." :)))

(ничего не хочу сказать плохого про ИШ, но ты их переписку почитай)

> oxffff © (09.03.07 17:33) [62]
> Вот здесь и заключается приимущество helperа.
> Но стоит вводить helper из-за этого.
> oxffff © (09.03.07 17:41) [66]
> Делов то.
> угу. Вы не находите, что предлагаете ПОЛНЫЙ аналог хелперов,
> но этот аналог обильно присыпан граблями?

Посмотрите oxffff © (09.03.07 17:12) [46].

Опишете грабли.

либо non type safe

ClassA=class

end;
classB=Class(ClassA)

end;

var b:ClassB;

b:=ClassB(ClassA.create);

Non Type safe
решается просто

Вводом всего лишь ключа {$HelperСlass}.
Который позволяет приводить типы.

И всего.

Никаких синтаксических конструкций.

to jack128.

Можете даже назвать ключ {$RestrictFieldsDeclaration}

Есть еще вариант решения non type safe

class operator Implicit(Obj:ClassA):ClassB;

Игорь Шевченко © (09.03.07 18:08) [68]
модульность гораздо важнее, не правда ли ?
Без сомнения.

Хе. Игорь, а теперь вспомним зачем водятся хелперы. Они вводят для того, чтобы ввести доп. функционал в те классы, изменить которые мы не можем. System.Object в .NET (для борланда - он недоступен). Тоже самое с TStream. Прикладной программист не может добавить новый код в Classes.pas

oldman © (09.03.07 18:09) [69]
Хамить-то зачем? © oldman

oxffff © (09.03.07 18:27) [76]
class operator Implicit(Obj:ClassA):ClassB;
для классов - нельзя переопределить операторы. Под Win32.

oxffff © (09.03.07 18:18) [73]
Вводом всего лишь ключа {$HelperСlass}.
чем ввод дополнительного ключа для компилятора, который фиг знает работает, отличается от ввода новой синтаксической конструкции?

oxffff © (09.03.07 18:20) [74]
Привидите пример с non type safe.
var
O: TSomeObject;
Helper: TSomeObjectHelper;
begin
...
Helper := TSomeObjectHelper(O);
...
SomeProc(Helper);
end;

procedure

Про хелперы.
Года 2-3 назад я выкладывал в кладовку (которая здесь была изначально) исходники, в которых было реализовано некое подобие хелперов для Delphi 7. Суть его была в следующем. Был создан базовый класс. К нему и его потомкам можно было во время исполнения добавлять методы от других потомков этого же базового класса. Таким образом, у объекта во время исполнения появлялись методы, которые не были предусмотрены при компиляции.

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

Возможная область применения хелперов: упрощение структуры и иерархии классов. Например, хелперы могли бы (возможно) решить дилемму глубина иерархии классов - сложность базовых классов. Т.е. часто приходится решать, какой вариант лучше: поместить как можно больше функциональности в базовый класс, тем самым минимизируя количество возможных потомков, либо в базовом классе реализовать минимально необходимую функциональность, а её расширение осуществлять путём наследования.

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

Примеры (названия классов и полей пишу по памяти, так что могу и ошибиться).
1. Поле PasswordChar в классе TEdit. Очень редко используемое поле. С хелперами можно было бы добавлять только к тем объектам TEdit, которым оно действительно нужно.

2. Свойство Dockable у класса TControl. Тоже не для всех контролов и не во всех проектах используется. Можно вынести в отдельный хелпер и подключать по мере необходимости.

3. Дублирование обычных контролов и DB-контролов. С хелперами можно было бы создать обычные контролы, а возможность работы с БД получалась бы подключением DB-хелпера.

jack128 © (09.03.07 18:28) [77]

Я помню, зачем вводятся helper"ы. Я также знаю, что для win32 существует масса более очевидных способов расширить функциональность классов. Ключевое слово - очевидность, код в первую очередь должен быть понятным, а видя в коде Memo.Lines.DoWork я в первую очередь теряюсь, во вторую прикладываю усилия для увольнения пишущего подобные вещи, потому что очевидность кода это гораздо более важная составляющая, чем факт использования новомодных фич.

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