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

← →
Игорь Шевченко © (2007-03-12 15:46) [200]

euru © (12.03.07 15:25) [199]

Про овощ все хорошо. Собственно, иллюстрация овоща не ко времени и была в примерах с Memo.Lines.DoWork

А при скрещивании System.Object и TObject helper"ы, как и овощи вполне себе приносят пользу.

← →
euru © (2007-03-12 15:56) [201]

> Игорь Шевченко © (12.03.07 15:46) [200]
Ну так если хелперы приносят пользу, будучи правильно применёнными, зачем же тогда от них отказываться?

Может, лучше тогда стоит отказываться от разработок, где они (по субъективному мнению оценивающего код) не несут никакой пользы?

← →
Игорь Шевченко © (2007-03-12 15:59) [202]

euru © (12.03.07 15:56) [201]

> Может, лучше тогда стоит отказываться от разработок, где
> они (по субъективному мнению оценивающего код) не несут
> никакой пользы?

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

← →
euru © (2007-03-12 16:29) [203]

> Игорь Шевченко © (12.03.07 15:59) [202]
Могу ли я сделать вывод, что мы пришли к взаимопониманию в отношении использования хелперов?
А именно. Хелперы - один из элементов синтаксиса языка программирования, сам по себе никак не влияющий на качество написания программ. Качество программ зависит от разработчика, применяющего эти хелперы (впрочем, как и другие возможности языка), а по их наличию в исходном коде ещё нельзя судить о квалифицированности специалиста.

← →
Игорь Шевченко © (2007-03-12 16:34) [204]

euru © (12.03.07 16:29) [203]

Да, конечно. То, что хелперы являюся элементом языка, это факт, от него никуда не деться. То, что качество программ зависит от разработчика, это тоже аксиома. С последним пунктом сложно согласиться/не согласиться, потому что о квалифицированности разработчика можно судить по применению иных элементов синтаксиса. То же самое относится к множественному наследованию, макросам и оператору goto :)

← →
euru © (2007-03-12 16:53) [205]

> Игорь Шевченко © (12.03.07 16:34) [204]
А как же

> Игорь Шевченко © (09.03.07 21:06) [96]
> Кстати, в случае DB-Aware controls неплохо бы на мой взгляд
> подошло множественное наследование
Вот встретится такое в твоём коде, и как тогда судить о квалификации? Или это время от времени вырывающиеся наружу пороки, с которыми идёт постоянная борьба? :)

← →
GrayFace © (2007-03-12 17:48) [206]

> http://hallvards.blogspot.com/
Чем только люди не страдают...

← →
Суслик © (2007-03-12 19:40) [207]

> [206] GrayFace © (12.03.07 17:48)
> > http://hallvards.blogspot.com/
> Чем только люди не страдают...

Почему? Ты имеешь что-то против?
Он что-то неверно написал? Может покажешь где (не имеются в виду опечатки)?

← →
Суслик © (2007-03-12 19:44) [208]

да... блин, а идея то благая была, блог завести.
даже мотивации нет что-то еще писать.

← →
Суслик © (2007-03-12 19:51) [209]

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

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

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

ну а кому она понятна с первого взгляда, то... не пойму я почему такие таланты за 10^6 уе не продаются?

ЗЫ
без обид - я привел мой личный опыт понятного когда.

← →
GrayFace © (2007-03-12 21:18) [210]

ТЮзер (в нете через паяльник) (11.03.07 23:13) [157]
Читаю, читаю, .... Кто-нибудь может привести примитивный пример, что такое эти хелперы, и где они удобны? У меня семерка.
Например, я бы сделал TObjectHelper function GetSelf Result:=self
Полезно будет в конструкции with. Чтобы не заводить переменную, а писать
with TMyObject do try DoSomething(GetSelf); finally end;

Суслик © (12.03.07 19:40) [207]
> [206] GrayFace © (12.03.07 17:48)
> > http://hallvards.blogspot.com/
> Чем только люди не страдают...

Почему? Ты имеешь что-то против?
Как так понял, все это ради того чтобы не писать наследник формы. Не понятно, в чем смысл.
Если же это действительно надо, то написали бы наследник, сняли с класса TForm/TCustomForm защиту от записи, изменили бы ссылку на таблицу свойств, пропатчили код TObject.NewInstance и FreeInstance, выделяли бы в нем доп. место под свои переменные либо заменили бы MemoryManager и делали это в нем. Все равно все это криво, но хоть меньше гмеорроя было бы.

Суслик © (12.03.07 19:44) [208]
да... блин, а идея то благая была, блог завести.
даже мотивации нет что-то еще писать.
А че? Давай пиши исчо, вон как хорошо пофлудили!

P.S. В "Delphi 2007 (часть I)" несколько раз "знаю" вместо "знают"

← →
Суслик © (2007-03-12 21:45) [211]

> P.S. В "Delphi 2007 (часть I)" несколько раз "знаю" вместо
> "знают"

да я не славлюсь аккуратностью

← →
oxffff © (2007-03-12 22:03) [212]

> Как так понял, все это ради того чтобы не писать наследник
> формы. Не понятно, в чем смысл.
> Если же это действительно надо, то написали бы наследник,
> сняли с класса TForm/TCustomForm защиту от записи, изменили
> бы ссылку на таблицу свойств, пропатчили код TObject.NewInstance
> и FreeInstance, выделяли бы в нем доп. место под свои переменные
> либо заменили бы MemoryManager и делали это в нем. Все равно
> все это криво, но хоть меньше гмеорроя было бы.

Можно их не трогать

Virtual method table layout
-40 Cardinal instance size in bytes

Но видимо не все так просто.

← →
GrayFace © (2007-03-12 23:02) [213]

Начинаю понимать, в чем дело, но не понятно, зачем понадобилось переменную затирать.

← →
GrayFace © (2007-03-12 23:12) [214]

oxffff © (12.03.07 22:03) [212]
Но видимо не все так просто.
Да, им было нужно чтоб интерфейс класса не менялся, т.к. иначе класс считается измененным и старые .dcu-шки не работают.

← →
Игорь Шевченко © (2007-03-12 23:47) [215]

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

Опыт дело наживное

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

Я упоминал. Понятная. Ты в коде VCL видишь какие-то непонятные места ? Берешь и читаешь, не испытывая дискомфорта.

Еще пример понятного кода - это "hello, world" на С

← →
euru © (2007-03-13 01:06) [216]

Может, не будем по второму кругу обсуждать полезность/бесполезность хелперов и их влияние на понимание и удобочитаемость кода? Вроде бы в [203] и [204] уже выяснили. :)

Кстати, "hello, world" на С сиспользованием WinAPI не таким уж и понятным выглядит при первом знакомстве.

> Суслик
А чем вызвано отсутствие полей в хелперах? Ведь согласно парадигме ООП данные и методы их обработки равноправны. Они составляют единое целое в классе. А в хелперах, являющихся составной частью класса, наблюдается явная дискриминация данных.

← →
oxffff © (2007-03-13 09:55) [217]

> А в хелперах, являющихся составной частью класса, наблюдается
> явная дискриминация данных.

По сути helper это набор external процедур и функций с неявным параметром object instance.
Абстракции данных он не порождает.

← →
euru © (2007-03-13 11:21) [218]

> oxffff © (13.03.07 09:55) [217]
Вот мне и интересно. Почему хелпер не может расширять абстракции данных? Какие могут возникнуть противоречия?

← →
oxffff © (2007-03-13 11:43) [219]

> расширять абстракции данных?

Это наследование.

class поля - теже глобальные переменные с ограниченным scope.

← →
euru © (2007-03-13 11:55) [220]

> oxffff © (13.03.07 11:43) [219]
Наследование - это создание нового класса, а хелпер - это внедрение в имеющийся класс. Это два разных способа расширения функциональности. Почему же тогда при наследовании возможно добавление данных, а при использовании хелперов - нельзя?

Ещё вопрос. Если хелпер добавить к классу, у которого есть потомки, появится ли у потомков методы хелпера?

← →
GrayFace © (2007-03-13 12:49) [221]

> А чем вызвано отсутствие полей в хелперах? Ведь согласно
> парадигме ООП данные и методы их обработки равноправны.
> Они составляют единое целое в классе. А в хелперах, являющихся
> составной частью класса, наблюдается явная дискриминация
> данных.

Суть не в парадигме, а в громоздкости реализации.

> Если хелпер добавить к классу, у которого есть потомки, появится ли у потомков методы хелпера?

Определенно да, т.к. имеются хелперы к TObject и TCustomForm, которые иначе не было бы возможности толком использовать. (сам не разу не использовал Delphi выше 7)

← →
oxffff © (2007-03-13 13:04) [222]

>Ещё вопрос. Если хелпер добавить к классу, у которого есть потомки, >появится ли у потомков методы хелпера?

A class helper is a type that - when associated with another class - introduces additional method names and properties which may be used in the context of the associated class (or its descendants).

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

A class helper simply introduces a wider scope for the compiler to use when resolving identifiers.

← →
jack128 © (2007-03-13 13:23) [223]

GrayFace © (12.03.07 23:12) [214]
т.к. иначе класс считается измененным и старые .dcu-шки не работают.
а зачем нужно чтоб старые дкушки читались? Вроде раньше на это забивали

← →
vuk © (2007-03-13 13:34) [224]

to jack128 © (13.03.07 13:23) [223]:
>а зачем нужно чтоб старые дкушки читались? Вроде раньше на это
>забивали
Эти меры предприняты только для D2007, хотели оставить бинарную совместимость dcu т.к. версия компилятора, как я понял, та же самая будет. Если совместимости не будет, это может повлиять на тех, кто использует коммерческие компоненты без исходников.

Я понял, что извращения с хелпером и фиктивными свойствами будут убраны в хайландере. Там уже будет и новая версия компилятора. И бинарной совместимости не будет.

← →
euru © (2007-03-13 16:38) [225]

> GrayFace © (13.03.07 12:49) [221]
> Суть не в парадигме, а в громоздкости реализации.
Т.е. добавление полей в хелперы сильно увеличивает громоздкость реализации по сравнению с реализацией хелперов только с методами? Почему?

← →
jack128 © (2007-03-13 16:48) [226]

euru © (13.03.07 16:38) [225]
Т.е. добавление полей в хелперы сильно увеличивает громоздкость реализации по сравнению с реализацией хелперов только с методами? Почему?
Насколько я понимаю основная сложность будет с рантайм пакетами.

← →
vuk © (2007-03-13 19:16) [227]

to euru © (13.03.07 16:38) [225]:
>Т.е. добавление полей в хелперы сильно увеличивает громоздкость
>реализации по сравнению с реализацией хелперов только с методами?
>Почему?
Уже кажется несколько раз повторялось. У хелперов нет экземпляров и, соответственно, места для хранения данных.

← →
euru © (2007-03-13 23:59) [228]

> vuk © (13.03.07 19:16) [227]
Я давно уже понял, что имеющаяся реализация хелперов в Delphi не предусматривает в них наличие полей. Просто мне пока непонятна, в чём принципиальная невозможность такой реализации.

Отсутствие у хелперов экземпляров, как мне кажется, не аргумент. Можно просто запретить объявление переменных с хелперными типами ещё при компиляции выдачей сообщения о синтаксической ошибке.

to euru © (13.03.07 23:59) [228]:
>Просто мне пока непонятна, в чём принципиальная невозможность такой
>реализации.
Экземпляр, он, по идее, монолитен должен быть. А хелперы применяться к одному и тому же экземпляру могут разные, в зависимости от контекста.

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

> vuk © (14.03.07 00:21) [229]
> Экземпляр, он, по идее, монолитен должен быть.
Но ведь при создании экземпляра класса у компилятора уже есть информация о применённых к этому классу хелперов. А значит, при выделении памяти под экземпляр класса можно учесть поля хелперов. А с другой стороны, почему экземпляр должен быть монолитен?

> Не понял, это-то здесь при чем?
Да, как-то я не так написал. Попробую по-другому. :)
Нужно просто запретить создание экземпляров хелперных типов. Они должны существовать только в контексте класса. Примерная аналогия - интерфейсы. Их реализация тоже не может существовать вне класса.

to euru © (14.03.07 00:47) [230]:
>Но ведь при создании экземпляра класса у компилятора уже есть
>информация о применённых к этому классу хелперов.
Откуда бы?

>А с другой стороны, почему экземпляр должен быть монолитен?
Ну как-то принято так... :)

>Нужно просто запретить создание экземпляров хелперных типов.
Ну так их и нет. Зачем что-то еще запрещать?

euru © (14.03.07 0:47) [230]
есть TObjectHelper = class helper for Tobject
Ffield: Integer;
end;
есть рантайм пакет собранный БЕЗ этого хелпера. Есть exe, юзающее этот пакет и этот хелпер. И как??

> vuk © (14.03.07 00:54) [231]

> Откуда бы?
Либо хелпер объявлен в текущем модуле, либо в разделе uses указан модуль, в которомобъявлен хелпер. Разве компилятору недостаточно информации?

> Ну как-то принято так... :)
Согласись, что это не является веским аргументом в пользу монолитного выделения памяти под объекты. :)

> Ну так их и нет. Зачем что-то еще запрещать?
Прекрасно. Т.е. одно из условий наличия хеперов с полями соблюдены. Что ещё мешает из появлению в языке?

> jack128 © (14.03.07 22:27) [232]
А зачем рантайм пакету знать о расширенных возможностях класса? Внутри пакета они всё равно не используются.

Если я, например, создам потомка от класса, имеющегося в пакете, неужели пакет не сможет работать с экземплярами моего потомка?

to euru © (15.03.07 00:11) [233]:
>Либо хелпер объявлен в текущем модуле, либо в разделе uses указан
>модуль, в которомобъявлен хелпер.
А если так: экземпляр по цепочке вызовов передается невесть куда в пакет (например динамически загруженный) и уже там на него навешивается хелпер. Что делать-то?

>Согласись, что это не является веским аргументом в пользу монолитного
>выделения памяти под объекты. :)
А скорость доступа к данным является аргументом?

euru © (15.03.07 0:11) [233]
А зачем рантайм пакету знать о расширенных возможностях класса?
затем, что раз есть в хелпере есть поле, то оно должно быть во всех классах. В том числе и тех, что были созданы кодом внутри пакета.
PS Я не говорю, что поля в хелпере невозможно реализовать. Все можно. Но цена - весьма высока.

vuk © (15.03.07 0:28) [234]
А если так: экземпляр по цепочке вызовов передается невесть куда в пакет (например динамически загруженный) и уже там на него навешивается хелпер. Что делать-то?

Ну да. Собственно я об этом же.

> vuk © (15.03.07 00:28) [234]

> А если так: экземпляр по цепочке вызовов передается невесть
> куда в пакет (например динамически загруженный) и уже там
> на него навешивается хелпер. Что делать-то?
Встречный вопрос. Экземпляр по цепочке вызовов передаётся невесть куда в пакет (например, динамически загруженный), в котором используется потомок класса данного экземпляра. Что произойдёт в таком случае?

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

> jack128 © (15.03.07 01:46) [235]

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

euru © (15.03.07 11:19) [237]
что такие же поля должны появится и у предков этого класса.
Не должны. Но есть поле появится к хелпере к TObject, то поле должно появиться во всех объектах.

euru © (15.03.07 11:19) [237]
Встречный вопрос. Экземпляр по цепочке вызовов передаётся невесть куда в пакет (например, динамически загруженный), в котором используется потомок класса данного экземпляра. Что произойдёт в таком случае?
а что должно произойти? Ну используется и используется.
jack128 © (15.03.07 15:55) [238]
Но ЕСЛИ поле появится к хелпере

euru © (13.03.07 16:38) [225]
Т.е. добавление полей в хелперы сильно увеличивает громоздкость реализации по сравнению с реализацией хелперов только с методами? Почему?
Хэлпер - это просто сборище функций, тут и реализовывать-то нечего (за исключением добавления синтаксиса)

Пусть в хелперах будут поля, у класса будет некий объем памяти, отведенный под хелперы. Дальше надо каждому хелперу дать смещение его данных относительно начала этого объема.
- Если это зашить в код, то сутуация: 2 пакета, в обоих по хелперу к одному и тому же классу. Оба пакета знают только о своих хелперах, значит у обоих смещение данных хелпера будет 0.
- Значит надо создавать переменную со смещением хелпера, при компиляции и дин. загрузке пакета ее заполнять и при каждом вызове метода хелпера к ней обращаться.
Теперь как можно добавить сам объем.
- Для каждого класса нужна будет переменная с размером этого блока. Опять же должна будет зполняться при динамической зарузке или компилянии программы.
Теперь возникают проблемы с самим заполнением этих переменных. Хотя вроде решаемо, придется менять vmt*, менять NewInstance, InitInstance, но вроде возможно.

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

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