И снова хелперы :)

← →
Суслик © (2007-04-11 00:57) [0]

Уважаемые, противники нововведний в дельфи.

Почитайте http://timokhov.blogspot.com/2007/04/blog-post.html
См. ссылку в посте.

ИМХО неплохо можно использовать новые фишки в языке. Разве нет?

← →
_Аноним (2007-04-11 10:17) [1]

Это в 2007 будет?

← →
Игорь Шевченко © (2007-04-11 10:35) [2]

> См. ссылку в посте.

Нет, чтоб перевести на понятный язык

← →
Чапаев © (2007-04-11 10:36) [3]

Капец... Давать ссылку на ссылку...

← →
_Аноним (2007-04-11 10:38) [4]

> Чапаев ©

Чтобы довести ситуацию до абсурда, можно знакомым давать эту ссылку:
http://delphimaster.net/view/15-1176238641/
"посмотрите, какие нововведения в delphi"
:-)

← →
Суслик © (2007-04-11 10:47) [5]

> [2] Игорь Шевченко © (11.04.07 10:35)
> > См. ссылку в посте.
> Нет, чтоб перевести на понятный язык

Ты про то, чтобы перевести?
Я подумаю об этом :)

> [1] _Аноним (11.04.07 10:17)
> Это в 2007 будет?

Вообще это все должно быть и БДС2006 (многое из описанного я использую в БДС2006). Другой вопрос, что в Д2007 это может постабильней работать. Это я точно не знаю, т.к. качеством работы итераторов доволен и в БДС2006. Как минимум ни одной ошибки не видел.

← →
Суслик © (2007-04-11 10:48) [6]

> [3] Чапаев © (11.04.07 10:36)
> Капец... Давать ссылку на ссылку...

ну себя тоже хочется попиарить :)

← →
Чапаев © (2007-04-11 10:49) [7]

> [6] Суслик © (11.04.07 10:48)
Тю... Так написал бы: подробности смотри в моём блоге по адресу "...". А то поди догадайся, что timokhov -- это ты... %-)

← →
_Аноним (2007-04-11 10:52) [8]

> Суслик ©

Пищи еще)
Я с каждого раза что-то новое узнаЮ :-)
вот про for in узнал
точнее, для перечислимых типов уже знал, а то что и по стринг листу работает - это новость

А читать "what"s new" при выходе новой версии - это не по нашему)

← →
Суслик © (2007-04-11 10:54) [9]

> А читать "what"s new" при выходе новой версии - это не по
> нашему)

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

правда, до указанного извращения я сам не додумался пока.

в what news можно только базовые новости почитать.

имхо

← →
euru © (2007-04-11 12:54) [10]

Ну да. Как только в хелпере понадобилось хранить состояние класса, а в самом классе "лишних" полей не нашлось, пришлось городить интерфейс и реализующий его класс. Хотя с этим вполне мог бы справиться сам компилятор.

Гипотетический пример:
TStringsEnumerator = class helper for TStrings private FIndex: Integer; function GetCurrent(): string; public function GetEnumerator(): TStrings; function MoveNext(): Boolean; property Current: string read GetString; end; function TStringsEnumerator.GetCurrent(): string; begin Result := Items[FIndex]; end; function TStringsEnumerator.GetEnumerator(): TStrings; begin; FIndex := -1; Result := Self; end; functions TStringsEnumerator.MoveNext(): Boolean; begin inc(FIndex); Result := FIndex < Count; end;

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

← →
Суслик © (2007-04-11 13:24) [11]

> [10] euru © (11.04.07 12:54

ты все о своем :)

← →
MBo © (2007-04-11 13:37) [12]

>euru
Где хранится дополнительное поле?

← →
euru © (2007-04-11 15:03) [13]

> Суслик © (11.04.07 13:24) [11]
> ты все о своем :)
Ну так видно же невооружённым глазом недоделанность хелперов. А в статье виден результат этой недоделанности. Весь код, который там нагромоздили только для того, чтобы сохранить текущую итерацию, мог бы с успехом сделать компилятор, и сделать это, я думаю, гораздо эффективнее.

А если учесть и другие несуразности, возникшие с вводом в язык новых понятий (о них я писал в [41] в http://delphimaster.net/view/15-1176238641/), то у меня возникают вопросы о квалифицированности разработчиков языка либо об их отношению к языку.

> MBo © (11.04.07 13:37) [12]
> Где хранится дополнительное поле?
Там же, где и остальные поля класса. Компилятор-то во время компиляции обладает информацией о наличии у класса хелперов и, соответственно, может учесть при выделении памяти имеющиеся в хелпере поля.

← →
oxffff © (2007-04-11 15:18) [14]

> euru © (11.04.07 15:03) [13]
>
> > Суслик © (11.04.07 13:24) [11]
> > ты все о своем :)
> Ну так видно же невооружённым глазом недоделанность хелперов.
> А в статье виден результат этой недоделанности. Весь код,
> который там нагромоздили только для того, чтобы сохранить
> текущую итерацию, мог бы с успехом сделать компилятор, и
> сделать это, я думаю, гораздо эффективнее.

Вы предлагаете ввести поля в хелперы.
Объясните нам тогда разницу по вашему между
наследованием и HelperEx(с полями).
Покажите на примере, что можно сделать с использованием того и другого.
А чего нельзя. И что это даст.

← →
Суслик © (2007-04-11 15:20) [15]

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

я думаю ты не прав :)
есть ощущение, что ты не до конца догоняешь (честное слово) хелперы.

хорошо, дабы не быть голословным

есть пакет А, в нем класс КлассА.
есть пакет Б, используется пакет А, в пакете Б есть ХелперБ.

И что? Кто должен учитывать доп. место? Пакет А ничего не знает о пакете Б. При этом пакет А может создавать объект.

Убедил?

← →
oldman © (2007-04-11 15:20) [16]

> Суслик © (11.04.07 00:57)
> Уважаемые, противники нововведний в дельфи.
> ИМХО неплохо можно использовать новые фишки в языке. Разве
> нет?

Нет.
Это будет уже другой язык.

(Кстати, а кто тебе сказал, что Дельфи - это язык программирования???)

← →
oxffff © (2007-04-11 15:21) [17]

> (Кстати, а кто тебе сказал, что Дельфи - это язык программирования?
> ??)

А что на нем уже разговаривают?

← →
Суслик © (2007-04-11 15:23) [18]

> [16] oldman © (11.04.07 15:20)

> (Кстати, а кто тебе сказал, что Дельфи - это язык программирования???)

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

-----
в одном могу согласится с общественностью - это уже тянет не другой язык с неизвестным будущем :)

← →
oldman © (2007-04-11 15:45) [19]

> oxffff © (11.04.07 15:21) [17]

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

А то как наш бухгалтер:
"Сергей, мы купили новый компьютер, поставьте нам какую-нибудь программу. Ну, хотя-бы, Виндоуз..." :)

← →
euru © (2007-04-11 15:47) [20]

> oxffff © (11.04.07 15:18) [14]
Наследование - это экстенсивный путь развития класса. Расширение функциональности класса производится за счёт создания его потомков.

Хелперы - это интенсивный путь развития класса. Расширение производится за счёт непосредственного встраивания в класс новой функциональности.

Примеры я повторю из одного из своих предыдущих сообщений.

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

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

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

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

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

← →
homm © (2007-04-11 15:50) [21]

> Вообще-то (имхо) Дельфи является средой программирования,
> использующую ObjectPascal, который и является языком программирования...

Здесь не может быть «имхо», имхо. :) Начяная с версии 7 язык называется Delphi.

← →
homm © (2007-04-11 15:51) [22]

Люди, вообще, учитесь отличать imho от afaik, а то суете не к месту и путаете вечно :(

← →
oxffff © (2007-04-11 15:51) [23]

> oldman © (11.04.07 15:45) [19]
>
> > oxffff © (11.04.07 15:21) [17]
>
>
> Вообще-то (имхо) Дельфи является средой программирования,
> использующую ObjectPascal, который и является языком программирования.
> ..
>
> А то как наш бухгалтер:
> "Сергей, мы купили новый компьютер, поставьте нам какую-
> нибудь программу. Ну, хотя-бы, Виндоуз..." :)

http://ru.wikipedia.org/wiki/Delphi_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

Delphi — результат развития языка Турбо Паскаль, который, в свою очередь, развился из языка Паскаль. Паскаль был полностью процедурным языком, Турбо Паскаль начиная с версии 5.5 добавил в Паскаль объектно-ориентированные свойства, а Delphi — объектно-ориентированный язык программирования с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде, также называемом интроспекцией. Так как все классы наследуют функции базового класса TObject, то любой указатель на объект можно преобразовать к нему, и воспользоваться методом ClassType и функцией TypeInfo, которые и обеспечат интроспекцию. Также отличительным свойством Дельфи от С++ является отсутствие возможности располагать объекты в стеке (объекты, унаследованные из Турбо Паскаля, располагаться в стеке могут) — все объекты попадают в динамически выделяемую область (кучу).

Де-факто Object Pascal, а затем и язык Delphi являются функциональными наращиваниями Turbo Pascal. Об этом говорят обозначения версий компилятора. Так, в Delphi 7 компилятор имеет номер версии 15.0 (Последняя версия Borland Pascal / Turbo Pascal обозначалась 7.0, в Delphi 1 компилятор имеет версию 8.0, в Delphi 2 — 9.0, и т. д. Номер версии 11.0 носит компилятор Pascal, входивший в состав среды C++Builder).

← →
oldman © (2007-04-11 15:57) [24]

> homm © (11.04.07 15:50) [21]
> Начяная с версии 7 язык называется Delphi.

Как работал на 5, так и работаю... :)))

← →
Игорь Шевченко © (2007-04-11 16:00) [25]

А что, неплохая иллюстрация к моим размышлениям о helper"ах - фича ради фичи

← →
oxffff © (2007-04-11 16:01) [26]

> euru © (11.04.07 15:47) [20]
>
> > oxffff © (11.04.07 15:18) [14]
> Наследование - это экстенсивный путь развития класса. Расширение
> функциональности класса производится за счёт создания его
> потомков.
>
> Хелперы - это интенсивный путь развития класса. Расширение
> производится за счёт непосредственного встраивания в класс
> новой функциональности.

Если вы встраиваете новую функциональность, то это уже другой класс.

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

Это делаете наследованием или делегированием реализации.

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

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

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

Просто так вы не встроите поле.
Вам нужно менять функциональность класса.
Куда вы это страиваете для новой функциональности, если это не предусмотрено заранее

← →
oldman © (2007-04-11 16:04) [27]

> Игорь Шевченко © (11.04.07 16:00) [25]
> А что, неплохая иллюстрация к моим размышлениям о helper"ах
> - фича ради фичи

Вообще, наводит на размышления перевод слова "helper"...
Это типа Шойгу - фича ради фичи.
:)))

← →
euru © (2007-04-11 16:24) [28]

> Суслик © (11.04.07 15:20) [15]
> есть пакет А, в нем класс КлассА.есть пакет Б, используется
> пакет А, в пакете Б есть ХелперБ.И что? Кто должен учитывать
> доп. место? Пакет А ничего не знает о пакете Б. При этом
> пакет А может создавать объект.
В пакете А вызывается конструктор класса КлассА. При вызове конструктора происходит обращение к RTTI этого класса. RTTI знает о наличии хелперов у класса, а также о размере выделяемой для класса памяти с учётом всех имеющихся хелперов. На основе этой информации выделится требуемое количество памяти. Методам класса из пакета А будут доступны только поля класса (про остальные поля они просто не знают). Методам хелпера из пакета Б будут доступны задекларированные в них поля.

> В пакете А вызывается конструктор класса КлассА. При вызове
> конструктора происходит обращение к RTTI этого класса. RTTI
> знает о наличии хелперов у класса, а также о размере выделяемой
> для класса памяти с учётом всех имеющихся хелперов.

Скажите как будет производится доступ к полям хелпера.
Offset уже могут быть разные?
через RTTI?

> oxffff © (11.04.07 16:01) [26]
> Если вы встраиваете новую функциональность, то это уже другой класс.
Это почему? Я как объявлял TStringList, так и буду продолжать. О наличии хелпера TStringsEnumerator будет заботится компилятор.

> Это делаете наследованием или делегированием реализации.
Допустим, у нас имеется следующая иерархия классов:
type TA = class . . . end; TB = class(TA) . . . end; TC = class(TA) . . . end;
Через некоторое время оказалось, что у классов ТВ и ТС имеется общая функциональность, которая не была учтена в классе ТА. Исходные коды для внесения поправок недоступны. Как это будет реализовано с использованием наследования или делегирования?

> Просто так вы не встроите поле.
> Вам нужно менять функциональность класса.
Конечно. Кроме описания полей нужно ещё будет перекрыть виртуальные методы класса.

> RTTI знает о наличии хелперов у класса

А нафига тогда helper"ы вообще ?

> Через некоторое время оказалось, что у классов ТВ и ТС имеется
> общая функциональность, которая не была учтена в классе
> ТА. Исходные коды для внесения поправок недоступны.

Значит и поправки недоступны, нес па ?

> Через некоторое время оказалось, что у классов ТВ и ТС имеется
> общая функциональность, которая не была учтена в классе
> ТА. Исходные коды для внесения поправок недоступны. Как
> это будет реализовано с использованием наследования или
> делегирования?

Кем не учтена? Вами? Автором?

> Просто так вы не встроите поле.
> Вам нужно менять функциональность класса.
Конечно. Кроме описания полей нужно ещё будет перекрыть виртуальные методы класса.

Модифицируемые методы могут быть не виртуальные(не динамические).

Самое главное, то что изменяется VTB и DMT класса.
А это уже другой класс.

Скажите как будет производится доступ к полям хелпера.
Offset уже могут быть разные?
через RTTI?

VTB = VMT

> Игорь Шевченко © (11.04.07 16:58) [32]
> Значит и поправки недоступны, нес па ?
При наследовании и делегировании недоступны. С хелперами это разрешимо.
type TAHelper = class helper for TA . . . end;
Классы TВ и ТС автоматически получат дополнительную функциональность хелпера.

> Через некоторое время оказалось, что у классов ТВ и ТС имеется
> общая функциональность, которая не была учтена в классе
> ТА. Исходные коды для внесения поправок недоступны

> При наследовании и делегировании недоступны. С хелперами
> это разрешимо.
> type
> TAHelper = class helper for TA
> . . .
> end;
> Классы TВ и ТС автоматически получат дополнительную функциональность
> хелпера

пример в студию не затруднит ?
исходные тексты TA, TB, TC недоступны

> oxffff © (11.04.07 17:02) [33]
> Кем не учтена? Вами? Автором?
Не учтена тем, кто создавал эту иерархию. А последующие разработчики по различным причинам (в том числе и юридическим) не могут/не имеют права вносить коррективы.

> Модифицируемые методы могут быть не виртуальные(не динамические).
Точно такая же проблема есть и при наследовании, однако она почему-то не приводит к отказу от этой парадигмы.

> Самое главное, то что изменяется VTB и DMT класса. А это
> уже другой класс.
Для компилятора, возможно, и другой. Для разработчика останется тем же.

> Скажите как будет производится доступ к полям хелпера.
> через RTTI?
А почему бы и нет?

← →
_Аноним (2007-04-11 17:27) [38]

Зачем спорить о том, чего нет? :-)

> _Аноним (11.04.07 17:27) [38]
> Зачем спорить о том, чего нет? :-)

А мало тут было веток про НЛО, барабашек, пиво за 2.20???

> _Аноним (11.04.07 17:27) [38]
> Зачем спорить о том, чего нет? :-)
Но это может появиться в будущем.

И снова хелперы :) Найти похожие ветки