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

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

jack128 © (09.03.07 18:28) [77]

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

← →
oxffff © (2007-03-09 18:34) [81]

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.

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

Сории, случайно надал отправить.

oxffff © (09.03.07 18:20) [74]
Привидите пример с non type safe.

procedure SomeProc(O: Tobject); forward; ... var O: TSomeObject; Helper: TSomeObjectHelper; begin ... Helper := TSomeObjectHelper(O); ... SomeProc(Helper); end; procedure SomeProc(O: Tobject); begin if O is TSomeObjectHelper then ... else ... end;

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

oxffff © (09.03.07 18:34) [81]
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.
И как это протеворечит тому, что пишу?

← →
oxffff © (2007-03-09 18:39) [84]

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

function RefUniversalConverter(a:pointer):pointer
begin
result:=a;
end;

Либо аdapter.

>
> 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

Подробнее пожалуйста.

← →
oxffff © (2007-03-09 18:44) [85]

> jack128 © (09.03.07 18:36) [82]
> Сории, случайно надал отправить.
>
> oxffff © (09.03.07 18:20) [74]
> Привидите пример с non type safe.
>
> procedure SomeProc(O: Tobject); forward;
>
> ...
>
> var
> O: TSomeObject;
> Helper: TSomeObjectHelper;
> begin
> ...
> Helper := TSomeObjectHelper(O);
> ...
> SomeProc(Helper);
> end;
>
> procedure SomeProc(O: Tobject);
> begin
> if O is TSomeObjectHelper then
> ...
> else ...
>
> end;

Мне не понятно, что тебе не нравиться.

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

oxffff © (09.03.07 18:44) [85]

Мне не понятно, что тебе не нравиться.
мне не нравится, что код
var
A: TSomeObjectHelper;
begin
...
Result := TObject(A) is TSomeObjectHelper;
end;
может вернуть False/

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

Игорь Шевченко © (09.03.07 18:34) [80]
Ключевое слово - очевидность, код в первую очередь должен быть понятным, а видя в коде Memo.Lines.DoWork я в первую очередь теряюсь,

Ну не знаю. Я не теряюсь. Для меня достаточно понятно. Для других программистов из наших - тоже. Мне этого факта - достаточно.

← →
oxffff © (2007-03-09 19:11) [88]

> jack128 © (09.03.07 18:52) [86]
> oxffff © (09.03.07 18:44) [85]
>
> Мне не понятно, что тебе не нравиться.
> мне не нравится, что код
> var
> A: TSomeObjectHelper;
> begin
> ...
> Result := TObject(A) is TSomeObjectHelper;
> end;
> может вернуть False/

А какое это отношение имеет к моим примерам.
И зачем передавать A в функцию.

← →
oxffff © (2007-03-09 19:16) [89]

Интерес вызывает другое

ClassA=class helper for tObject
procedure abc;
end;

Я могу объявить переменную
var
a:Tobject;
b:ClassA;
Только с ней сделать ничего не могу.

b. //e2018

b:=a //e2015
a:=b; //e2010

Что за чудеса?

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

> [89] oxffff © (09.03.07 19:16)

ты бы составлял примеры кода более понятно.
а то догадываться приходится о чем ты вообще говоришь.

← →
jack128 © (2007-03-09 19:29) [91]

oxffff © (09.03.07 19:16) [89]
Я могу объявить переменную
ИМХО - это баг. Хелперы как самостоятельные сущности - не имеют смысла.

← →
jack128 © (2007-03-09 19:31) [92]

oxffff © (09.03.07 19:11) [88]
А какое это отношение имеет к моим примерам.
И зачем передавать A в функцию.

То есть зачем? Знаешь, я таки иногда пишу функции и методы.. И иногда даже передаю в них параметры..

← →
oxffff © (2007-03-09 19:44) [93]

> jack128 © (09.03.07 19:31) [92]
> oxffff © (09.03.07 19:11) [88]
> А какое это отношение имеет к моим примерам.
> И зачем передавать A в функцию.
>
> То есть зачем? Знаешь, я таки иногда пишу функции и методы.
> . И иногда даже передаю в них параметры..

По твоему примеру не понятно, что тебя не устраивает.

Если у тебя

a:Tcontrol;
b:TwinControl;

a:=Tcontrol.create(nil);
b:=TwinControl(A);

procedure Check(a:Tobject);
begin
if a is Twincontrol then
else
end;

Будет всегда false. Что тебе не нравиться.

Тебе не надо инстанцировать Helper class. Ты просто приводишь к нему.
И все.

Если ты имел что то другое напиши. О чем ты.

Буду через час.

← →
Eraser © (2007-03-09 20:10) [94]

кстати, отвлекаясь от темы хелперов )

исправили ли наконец баг с горизонтальным "авто скролом" в редакторе кода, когда печатаешь русскими буквами (коментарии, константы)?

← →
GrayFace © (2007-03-09 20:48) [95]

euru © (09.03.07 18:33) [79]
С хелперами можно было бы реализовать второй вариант, а дополнительные возможности подключать к базовому классу или его потомкам по мере необходимости.
Это, как раз, неправильный способ их использования.

euru © (09.03.07 18:33) [79]
1. Поле PasswordChar в классе TEdit. Очень редко используемое поле. С хелперами можно было бы добавлять только к тем объектам TEdit, которым оно действительно нужно.
Оно же в оболочке используется, значит обязано присутствовать в TEdit!

Игорь Шевченко © (09.03.07 18:34) [80]
Ключевое слово - очевидность, код в первую очередь должен быть понятным, а видя в коде Memo.Lines.DoWork я в первую очередь теряюсь, во вторую прикладываю усилия для увольнения пишущего подобные вещи, потому что очевидность кода это гораздо более важная составляющая, чем факт использования новомодных фич.
С непривычки?

jack128 © (09.03.07 18:52) [86]
var
A: TSomeObjectHelper;
begin
...
Result := TObject(A) is TSomeObjectHelper;
end;
может вернуть False/
Ну и что?

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

euru © (09.03.07 18:33) [79]

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

Это вряд ли. Механизм хелперов предусматривает только дополнительные методы с уже имеющимися свойствами (или с классовыми свойствами, что в данном случае тоже несильно применимо).

Кстати, в случае DB-Aware controls неплохо бы на мой взгляд подошло множественное наследование и наследуясь от простого контрола и TdataLink можно было бы получать нужный результат. При этом сохранялась бы возмножность независимой модификации обоих базовых классов.

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

GrayFace © (09.03.07 20:48) [95]

> С непривычки?

Дорогой друг, привычка - это сэкономленное время.
Впрочем, кто в молодости не был радикалом...

← →
jack128 © (2007-03-09 21:16) [98]

GrayFace © (09.03.07 20:48) [95]
Ну и что?
То что декларируемое - не соответствует действительному. Это еще допустимо во внутренней реализации классов (думаю многие хранили Integer в TList"е), но тут подобное несоответствие будет везде, где будут используются эти псевдохелперы. Нафиг-нафиг-нафиг.

Игорь Шевченко © (09.03.07 21:06) [96]
неплохо бы на мой взгляд подошло множественное наследование и
БИНГО! :-D

← →
oxffff © (2007-03-09 23:10) [99]

to jack128
Ответьте на oxffff © (09.03.07 19:44) [93]

← →
oxffff © (2007-03-09 23:34) [100]

> То что декларируемое - не соответствует действительному.
> Это еще допустимо во внутренней реализации классов (думаю
> многие хранили Integer в TList"е), но тут подобное несоответствие
> будет везде, где будут используются эти псевдохелперы. Нафиг-
> нафиг-нафиг.

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

← →
jack128 © (2007-03-09 23:50) [101]

oxffff © (09.03.07 19:44) [93]
a:=Tcontrol.create(nil);
b:=TwinControl(A);

Ну.. Видя такой код
я в первую очередь теряюсь, во вторую прикладываю усилия для увольнения пишущего подобные вещи, © Игорь Шевченко ;-)

Еще раз: Ты предлагаешь те же хелперы, но обильно присыпанные граблями.

← →
euru © (2007-03-10 00:06) [102]

> GrayFace © (09.03.07 20:48) [95]
> Это, как раз, неправильный способ их использования.
Неправильный концептуально или с точки зрения реализации хелперов в Delphi?

> Оно же в оболочке используется, значит обязано присутствовать
> в TEdit!
Честно говоря, про оболочку я не понял. В примере я рассматривал гипотетический TEdit, а не из VCL.

> Игорь Шевченко © (09.03.07 21:06) [96]
Это, я так понимаю, поведение хелперов, реализованных в Delphi.
Я же рассматривал для чего вообще можно применять хелперы.

← →
oxffff © (2007-03-10 00:25) [103]

> jack128 © (09.03.07 23:50) [101]
> oxffff © (09.03.07 19:44) [93]
> a:=Tcontrol.create(nil);
> b:=TwinControl(A);
>
> Ну.. Видя такой код
> я в первую очередь теряюсь, во вторую прикладываю усилия
> для увольнения пишущего подобные вещи, © Игорь Шевченко
> ;-)
>
> Еще раз: Ты предлагаешь те же хелперы, но обильно присыпанные
> граблями.

Хорошо. Паттерн адаптер тебя не устраивает?

← →
oxffff © (2007-03-10 00:35) [104]

> > Еще раз: Ты предлагаешь те же хелперы, но обильно присыпанные
>
> > граблями.

Граблей нет. Мне кажется грабли пытаешься ты сам выдумать. И у тебя не получается.

Особенно про это

A: TSomeObjectHelper;
begin
...
Result := TObject(A) is TSomeObjectHelper;
end;
может вернуть False/

Будет всегда возвращать false
Тебе нужно просто использовать with HelperClass(BaseClassObj) и всего.

Если тебе не нравиться жесткое приведение типов используй RefUniversalConverter. Можно даже inline.

Либо адаптер.

Граблей нет.

:(

Соорудили сомнительный велосипед под названием Helper. Зачем?

Пусть будет?

← →
jack128 © (2007-03-10 00:44) [105]

oxffff © (10.03.07 0:25) [103]
Паттерн адаптер тебя не устраивает?

вполне. Но он предусматривает создание НОВОГО объекта. Собственно у нас так и есть, есть некий
TGsFiler = class
public
constrcutor Create(AStream: TStream);
function ReadString: string;
procedure WriteString(const S: string);
// И далее по списку.
end;

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

← →
jack128 © (2007-03-10 00:49) [106]

oxffff © (10.03.07 0:35) [104]
Тебе нужно просто использовать with HelperClass(BaseClassObj) и всего.
вот вот. То есть я должен всегда использовать ЗАВЕДОМО небезопасную конструкцию.
Сие есть - плохо. И это не обсуждается. Прямое привидение типов для объектов лично я стараюсь не использовать, после того, как пару часов искал опечатку...

oxffff © (10.03.07 0:35) [104]
используй RefUniversalConverter
Что это такое?

← →
jack128 © (2007-03-10 00:56) [107]

Ладно, я выхожу из обсуждения. Чуствую - все останутся при своих мнениях.

← →
GrayFace © (2007-03-10 11:59) [108]

euru © (10.03.07 0:06) [102]
Неправильный концептуально или с точки зрения реализации хелперов в Delphi?
Я про Дельфийские. Если б не было ограничения [38], то не знаю, насколько такое было бы хорошо. Вообще, как-то нелогично - если реализовывать функциональность в гепотетических хелперах, то им вполне могут понадобиться переменные, а их надо добавлять в самом классе, все получается нараскарячку. А если в гипотетических хелперах иметь возможность объявлять переменные, то это либо ничем не отличается от множественного наследования, либо несет еще больше граблей.

> Ладно, я выхожу из обсуждения. Чуствую - все останутся при
> своих мнениях.

Да нет, это диалог. Я могу с вами согласиться.
Что мне лично не нравиться, так это новая синтаксическая конструкция.
И всего. А так я разделяю и вашу точку зрения.

Нужны дополнения в язык. Только их необходимо взвесить, главное без оглядки .NET. Хотя это не реально.
Они же хотят mix-ить managed и Unmanaged код на Delphi в будущем.

euru © (10.03.07 00:06) [102]

> Это, я так понимаю, поведение хелперов, реализованных в
> Delphi.
> Я же рассматривал для чего вообще можно применять хелперы.
>

А хелперов вроде нигде больше нету. В C# насколько мне известно вообще никакие примеси не разрешены, в С++ полностью реализовано множественное наследование, что происходит в Java - честно говорю, не знаю. Про остальные языки ничего не говорю, потому что не распространены.

> GrayFace © (10.03.07 11:59) [108]

> Я про Дельфийские.
Про эти ничего не могу сказать из-за неимения Delphi. Но по обсуждению в этой ветке, я так понял, на них наложено множество ограничений, которые не позволяют в полной мере использовать их возможности. Вообще, как мне показалось из периодически возникающих здесь тем, появляющиеся в Delphi новые возможности чаще всего носят не концептуальный, а конъюнктурных характер. При этом в погоне за модой, конкурентами вводятся дополнительные понятия, но их концептуальность низка. Например, с одной стороны, ввели возможность в записях (record) использовать методы и остановились. А с другой стороны, в Delphi (по крайней мере, до 7-й версии) имеется тип object. Тот же record, только ещё имеется возможность наследования и полиморфизма. По-моему, лучше бы реабилитировали object или перенесли бы на record весь функционал object.

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

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

> [111] euru © (11.03.07 00:51)

> А с другой стороны, в Delphi (по крайней мере, до 7-й версии)
> имеется тип object. Тот же record

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

Eraser © (11.03.07 1:04) [112]
да и вообще, как по-мне, так не нужны в структурах методы, на то объекты существуют.
Нужны, например, для комплесных чисел.

> [113] euru © (11.03.07 01:09)

на сколько мне известно, обжекты поддерживают наследование.. да и методы у них есть, хоть и статические, т.о. обжект это не просто участок памяти со строго обозначенные поля, размер которого равен сумме этих полей + выравнивание, к которым есть прямой доступ у юзера, а какие-то поля + метаданные, находящиеся в самом объекте. По-моему методы в записях реализованы через compiler magic.

> [114] GrayFace © (11.03.07 01:25)

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

> Eraser © (11.03.07 01:29) [115]
Реализация функциональности в языке программирования, по-моему, не слишком должна беспокоить программиста.

Концептуальное различие между типами class и object в том, что выделение памяти для объектов типа class происходит динамически (при вызове их конструктора), а для объектов типа object - статически, как для обычных переменных. Во всём остальном эти типы, в принципе, схожи.

Теперь сравним типы record и object. Оба типа являются структурами, содержащими поля других типов. Как для record, так и для object память выделяется статически во время компиляции. Это их сходства. Различия заключаются в том, что record предназначен только для хранения данных, а object кроме этого содержит в себе также методы обработки этих данных, а также позволяет управлять областью их видимости и возможностями наследования и полиморфизма.

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

Eraser © (11.03.07 1:31) [116]
В данном случае должны применяться объекты тогда, но это в идеале, когда компьютеры будут мощные и памяти будет много.. ))
В Delphi и применяются Custom Variants для этого, но это очень громоздко.

Eraser © (11.03.07 1:29) [115]
на сколько мне известно, обжекты поддерживают наследование.. да и методы у них есть, хоть и статические
Даже виртуальные возможны, и конструкторы с деструкторами %)

Eraser © (11.03.07 1:29) [115]
По-моему методы в записях реализованы через compiler magic.
Ну думаю, что это чем-то отличается от методов в объектах и классах. Только что такое compiler magic?

> Eraser © (11.03.07 1:29) [115]
> на сколько мне известно, обжекты поддерживают наследование.
> . да и методы у них есть, хоть и статические
> Даже виртуальные возможны, и конструкторы с деструкторами
> %)

Еще и динамические.

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