Какой смысл оформлять классы, не имеющие...

← →
Kolan © (2006-12-10 23:11) [80]

Э, ребзя вы че? Теперь и я захотел...

← →
vuk © (2006-12-10 23:13) [81]

to Cyrax © (10.12.06 22:52) [69]:
>Возьмём к примеру, UML.
Не, не возьмём. Он здесь ни при чем и к .dfm отношения не имеет. :)

to Юрий Зотов © (10.12.06 23:05) [72]:
>Я вот щас коньячку принял, немножко. Бархатный, подлец.
Издеваешься!? Вот негодяй! :))

← →
Юрий Зотов © (2006-12-10 23:13) [82]

О!!! Дискуссия явно оживилась!!!

← →
Джо © (2006-12-10 23:14) [83]

Да. Возьмем это UML. За это самое... И в окошко. %)

← →
Алхимик © (2006-12-10 23:16) [84]

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

← →
Юрий Зотов © (2006-12-10 23:17) [85]

А в слове "UML" последняя буква - это ""liquid", надеюсь?

← →
Юрий Зотов © (2006-12-10 23:18) [86]

> Алхимик © (10.12.06 23:16) [84]

Наш человек! Сразу видно - настоящий программер!

← →
Павел Калугин © (2006-12-10 23:20) [87]

> [82] Юрий Зотов © (10.12.06 23:13)

Садист, однозначно.....

← →
Алхимик © (2006-12-10 23:20) [88]

> [86] Юрий Зотов © (10.12.06 23:18)
> > Алхимик © (10.12.06 23:16) [84]
>
> Наш человек! Сразу видно - настоящий программер!

Дядя Юра, а можно я эту цитату в своё резюме впишу?
Мой потенциальный работодатель оценит на все сто процентов!
:)

← →
Джо © (2006-12-10 23:21) [89]

> [85] Юрий Зотов © (10.12.06 23:17)
> А в слове "UML" последняя буква - это ""liquid", надеюсь?

Угу.
Undefined Malicious Liquid :_)

← →
Kolan © (2006-12-10 23:23) [90]

> А в слове "UML" последняя буква - это ""liquid", надеюсь?

Unified Mindclearing Liquid :)

Садисты, а мне пропустить грамм 250 невыйдет сейчас, а хочется... :)

← →
Юрий Зотов © (2006-12-10 23:25) [91]

> Павел Калугин © (10.12.06 23:20) [87]

Причем того самого, Паш. Ну, ты знаешь, какого. Зацени мою сволочность?

> Алхимик © (10.12.06 23:20) [88]

Без проблем. Но 40 процентов гораздо лучше, чем 100.

← →
Юрий Зотов © (2006-12-10 23:26) [92]

> Kolan © (10.12.06 23:23) [90]

> Mindclearing

Браво!

← →
Cyrax © (2006-12-10 23:29) [93]

>@BraIN © (07.12.06 23:19) [42]
>— Вон поскакал «неуловимы Джо»...
>— А почему неуловимый?
>— А кому он собственно нужен?

Скажу честно: зачёт...

>Юрий Зотов © (08.12.06 01:01) [43]
>То есть, возражать-то можно сколько угодно, но для того, чтобы твои
>возражения хотя бы были приняты, как возражения (уж не говоря о том,
>чтобы с ними согласились), нужно, чтобы тот, кому возражают ну хотя бы
>немного разбирался в вопросе. Ну хотя бы чуть лучше табуретки.
>А если он в вопросе разбирается именно на уровне табуретки и не более,
>то хоть обвозражайся - не поймет. Потому что понять просто не может.
>И, значит, будет считать, что "достойно возразить" ему так и не смогли.

lol... так вы мне возражайте...

>Вы, конечно, знаете, чем отличается ламер от чайника, да?

Знаю...

>Юрий Зотов © (08.12.06 01:07) [44]
>Раньше я считал, что ламер - это воинствующий чайник. И жизнь это не
>раз подтверждала.
>Но тут определилась новая разновидность - воинствующий (причем весьма
>активно), но даже до чайника не дотягивает (причем весьма сильно).
>Воинствующая табуретка? Этакий табуламер?

1 вариант: получаю RO, предварительно ответно оторвавшись...
2 вариант: отшучиваюсь и ухожу в сторону...
3 вариант: пытаюсь показать некорректность нападков, нет, лучше наездов...

Ни одного из вариантов тут не реализую. Элементы 1 варианта проимплементированы мысленно, для 2-го слишком трезв, 3-й - слишком "правильный".

>Джо © (08.12.06 01:10) [45]
>Никакой новой разновидности, ИМХО. Просто ламер-провокатор, как
>собственно он и сам признавался.

В чём конкретно я признавался ?
Подтверди конкретным примером... (мог бы дописать: либо... - а дальше придумать что-нибудь для тебя неприятное. Но это слишком предсказуемо и банально)

>Германн © (08.12.06 01:58) [50]
>Ну вот. ЮЗ расширяет свою (нашу) классификацию ламеров :-)
>Запомним, чтобы ввести Кэтмара в курс дела, когда он вернётся.

Судя по всему, привычнее, когда в аналогичной ситуации наблюдается бурная негативная реакция, заканчивающаяся RO. Я же такого удовольствия никому доставлять не собираюсь.
Кроме того, подобные высказывания - это всего лишь очередная попытка показать и почуствовать себя крутым перцем, ветка же - всего лишь повод для этого.

>Другой © (08.12.06 01:14) [46]
>Этакий табуламер?
>Звучит ниче так.

Тоже захотелось выпендриться.
Я не говорю, что это плохо, я всего-то факт констатирую...

>Anatoly Podgoretsky © (08.12.06 12:20) [55]
>> Юрий Зотов (08.12.2006 01:01:43) [43]
>> А если он в вопросе разбирается именно на уровне табуретки и не более, то
>>хоть обвозражайся - не поймет.
>Для лучшего понимания надо использовать табуретку по прямому назначению - по >голове. И так много раз.

Анатолий, вы во мне азарт пробуждаете. Вспомнил уж тут московскую "прописку", которую Gero обещал...

← →
Юрий Зотов © (2006-12-10 23:31) [94]

Вот так. Пришел Жан...

← →
Чапаев © (2006-12-10 23:35) [95]

> подобные высказывания - это всего лишь очередная попытка
> показать и почуствовать себя крутым перцем, ветка же - всего
> лишь повод для этого
Почувствовал?

← →
Джо © (2006-12-10 23:35) [96]

Нет, вы не поверите, до чего же полегчало. Просто заново родился.

← →
Cyrax © (2006-12-10 23:43) [97]

>vuk © (08.12.06 01:16) [47]
>>Нигде в коде этой инициализации нет.
>В коде она есть. В коде предка-контейнера.

Я говорю об инициализации в коде. Таковой не имеется. Это факт.

>А если говорить о явно
>прописываемой в коде инициализации, то по-хорошему, такая "
>инициализация" должна работать в обе стороны, то есть то, что написано
>руками должно влиять на внешний вид в конструкторе (т.н. Two Way).
>Насколько я понимаю, в native-среде такое сделать, скажем так,
>затруднительно. Вот Java/.net - пожалуйста. И в Delphi for .net все это
>тоже есть. И, кстати, никакого отношения все это не имеет к тому, как
>библиотека внутри устроена.

Ну так если изменить параметры в dfm-ке, то в конструкторе с большой вероятностью эти изменения отразятся...
Да и без two way можно запросто обойтись...

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

Более понятный пример привожу...

>dfm - это не исходный код !!!!
>Совершенно верно. Не код. С концепцией ресурсов знакомы?

А вот об этом можно и в отдельной ветке поговорить...)

← →
Cyrax © (2006-12-10 23:50) [98]

>Vga © (08.12.06 13:15) [63]
>> [54] Правильный Вася (08.12.06 11:21)
>Или более корректно: тот, кто хочет - всегда найдет возможность, тот, кто >не хочет - всегда найдет отговорку.

Мне Васькино высказывание больше нравится - как более агрессивное...
Что по делу, то вещь реализуемая, можешь выбрать компонент, который требуется реализовать более эффективно (с невизуальной ориентацией) и быстрее...
(займёт 3 место в очереди проектов (Default - Ketmar - Vga))///

← →
Romkin © (2006-12-10 23:53) [99]

Юрий Зотов © (10.12.06 23:31) [94] Как пришел, так и уйдет... А у меня проблема: есть коньяк, но я его не люблю :( просто для готовки...
Есть ведерко квашеной капусты, но нет водки :(
Какие тут компоненты, млин :(

← →
Virgo_Style © (2006-12-10 23:53) [100]

100-й пост на носу, а я все еще теряюсь в догадках, чем компонент с визуальной ориентацией отличается от компонента с невизуальной ориентацией

← →
Cyrax © (2006-12-10 23:55) [101]

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

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

← →
Cyrax © (2006-12-10 23:58) [102]

>Virgo_Style © (10.12.06 23:53) [100]
>100-й пост на носу, а я все еще теряюсь в догадках, чем компонент с
>визуальной ориентацией отличается от компонента с невизуальной
>ориентацией

Компонент с визуальной ориентацией ориентирован на визуальное применение, с невизуальной - на невизуальное...

← →
Чапаев © (2006-12-11 00:05) [103]

Самурай без меча подобен самураю с мечом. Но без меча.

← →
Cyrax © (2006-12-11 00:06) [104]

Если честно, то та ветка была довольно интересна... Лично я не против (это модераторам)...

← →
vuk © (2006-12-11 00:21) [105]

to Cyrax © (10.12.06 23:43) [97]:
>Таковой не имеется. Это факт.
Не имеется. И что?

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

>Да и без two way можно запросто обойтись...
Two way, оно либо есть, и тогда изменения в исходнике будут отображаться в дизайнере и наоборот, либо его нет.

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

Возмем банальную кнопку - TButton. Что там ориентировано на "визуальное применение" и чем от TButton будет отличаться кнопка, на это применение не ориентированная?

← →
Юрий Зотов © (2006-12-11 00:47) [106]

> vuk © (11.12.06 00:21) [105]

> чем от TButton будет отличаться кнопка, на это применение
> не ориентированная?

Леш, ты что, офигел, такие сложные вопросы задавать? А еще меня садистом обзываешь.

Из этой ветки следует, что под "визуальными компонентами" товарисч понимает то, что он видит сначала в палитре, а если бросить на форму - то и на форме. Еще визуальные компоненты обладают законченной функциональностью. То есть, TMenu - это у него визуальный компонент.

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

Леш, ты что, офигел, такие сложные вопросы задавать? А еще меня садистом обзываешь.

← →
ors_archangel © (2006-12-11 00:47) [107]

> Какой смысл оформлять классы, не имеющие...
> ...графического представления на экране, в виде компонентов
> ?

В этом согласен с Cyrax, может нужно было объединить визуальное и невизуальное, любой класс - квадратик с publishedными свойствами и наоборот, только не на форме, а отдельно, например, выбираешь класс в Explorerе, а в Инспекторе тебе его свойства можно редактировать, обработчики назначать. Хорошо, если бы была палитра классов, разложены по категориям/юнитам, удобно, берёшь его, перетаскиваешь куда-нить в код, даёшь имя, а юнит сам юзится автоматом, тогда невизуальное можно было бы отделить без потерь в скорости разработки... Обработчики - тоже согласен с Cyrax - совершенно не правильно, что отделены от классов, с которыми они связаны, если я, допустим, нажимаю на кнопку Button1, я бы хотел, чтобы это событие обрабатывалось в TButton1.ClickEvent каком-то что ли, ну не как в TForm1.Button1Click (хорошо хоть что не вообще глобальная функция как в Visual Basic), это не удобно хотя бы тем, что для доступа к полям, собсвенно, Button1, нужно разбираться кто есть Sender, вообще, когда я ввожу какию-нить переменную, связанную только с Button1, я не смогу её вствить в описание TButton1, потому что его просто нет, неужели надо создавать новый компонент для этого? По-моему, должна быть возможность расширять описание любого подкомпонента формы. Мне лично тоже не нравится концепция хранить начальные свойства и привязку событий в ресурсах (dfm), лучше бы генерация как dotnet, и чтобы изменять её можно было в редакторе (много хочу, наверно, а ведь в KOL/MCK что-то подобное уже есть), тогда бы и размер можно была контролировать как-то экзешников, но говорят же: лучшее - враг хорошего?

← →
Юрий Зотов © (2006-12-11 00:55) [108]

Руслан Сергеевич, с днем архангела Вас. Извините, что на день раньше.

А по поводу "когда я ввожу какию-нить переменную, связанную только с Button1, я не смогу её вствить в описание TButton1, потому что его просто нет, неужели надо создавать новый компонент для этого? По-моему, должна быть возможность расширять описание любого подкомпонента формы" разрешите Вас напомнить что есть такой краеугольный камень ООП, как наследование. И его пока не отменяли.

to Юрий Зотов © (11.12.06 00:47) [106]:
>Из этой ветки следует
Юр, я не люблю упражнений в телепатии и предпочитаю, чтобы человек сам рассказал, что он под чем понимает. Он пока не колется. Подождем. :)

to ors_archangel © (11.12.06 00:47) [107]:
>берёшь его, перетаскиваешь куда-нить в код, даёшь имя, а юнит сам
>юзится автоматом
Не, ну совсем народ обленился! :)

>я бы хотел, чтобы это событие обрабатывалось в TButton1.ClickEvent
Вы предлагаете на каждый чих рожать наследника от TButton? Или что Вы имеете в виду?

>По-моему, должна быть возможность расширять описание любого
>подкомпонента формы.
Есть два метода расширения функциональности - наследование и делегирование (через события). Какой Вы предпочитаете? И понимаете ли, что последует за использованием каждого из методов?

> Юрий Зотов © (11.12.06 00:55) [108]

> Руслан Сергеевич, с днем архангела Вас. Извините, что на
> день раньше.

Спасибо!
Значит можно писать:
TButton1 = class(TButton) somefield: TSomeType; end; TForm1 = class(TForm) Button1: TButton1; end;?
А в остальном согласен?

> vuk © (11.12.06 01:01) [109]

Какая-такая телепатия? Он уже все сам написал.

А ты, Леш, точно садист: "Есть два метода расширения функциональности - наследование и делегирование (через события). Какой Вы предпочитаете? И понимаете ли, что последует за использованием каждого из методов?".

Не, ну так нельзя. Хлопцы ж теперь спать не будут. Оказывается, все уже до них придумано, а мужики-то и не знали!

> ors_archangel © (11.12.06 01:08) [110]

> Значит можно писать:
> TButton1 = class(TButton)
> somefield: TSomeType;
> end;
> TForm1 = class(TForm)
> Button1: TButton1;
> end;

Руслан Сергеевич, а ведь можно. Вот чес-слово, можно. И даже проблем с DFM не будет, ежели писать ГРАМОТНО.

Руслан Сергеевич, извините, но может, сначала все-таки, книжки а уж потом мнения, а?

to ors_archangel © (11.12.06 01:08) [110]:
>Значит можно писать
Не все, что можно писать, нужно писать. :)

to Юрий Зотов © (11.12.06 01:08) [111]:
>Какая-такая телепатия? Он уже все сам написал.
Хде? Если тонким слоем по всей ветке, то лично меня это не устраивает. Хочу четкости определений. Да, я сволочь! :))

> >По-моему, должна быть возможность расширять описание любого
> >подкомпонента формы.
> Есть два метода расширения функциональности - наследование
> и делегирование (через события). Какой Вы предпочитаете?
> И понимаете ли, что последует за использованием каждого
> из методов?
>

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

// Программы есть для всего, просто они ещё не написаны

Всё, извините, пойду читать книжки :)

В общем, на днях продолжим...
(ors_archangel, к сожалению, сломался)

> Мне Васькино высказывание больше нравится

Двусмысленно - смотри мою анкету :)

> >vuk © (08.12.06 01:16) [47]
> >>Нигде в коде этой инициализации нет.
> >В коде она есть. В коде предка-контейнера.
>
> Я говорю об инициализации в коде. Таковой не имеется. Это
> факт.

Имеется. Это интерпретатор DFM, который зарыт где-то в недрах VCL и работает на основе RTTI и TComponent (AFAIK). Вместо того, чтобы плодить инициализационный код, они написали интерпретатор DFM, который в исполняемом файле в одном экземпляре независимо от количества форм и компонентов. Похожая система - DIALOG RESOURCE из WinAPI.

> В этом согласен с Cyrax, может нужно было объединить визуальное
> и невизуальное, любой класс - квадратик с publishedными
> свойствами и наоборот, только не на форме, а отдельно, например,
> выбираешь класс в Explorerе, а в Инспекторе тебе его свойства
> можно редактировать, обработчики назначать.

Зачем лишний механизм, когда уже есть подходящий? Лишний механизм = линшний код в исполняемом файле.

> Обработчики - тоже согласен с Cyrax - совершенно не правильно,
> что отделены от классов, с которыми они связаны, если я,
> допустим, нажимаю на кнопку Button1, я бы хотел, чтобы
> это событие обрабатывалось в TButton1.ClickEvent каком-то
> что ли

Плодить для каждой кнопки новый класс? Это прибавит веса исполняемому файлу и довольно заметно.
> нужно разбираться кто есть Sender,

Зачем, если этот обработчик у тебя привязан только к одной кнопке? Sender требуется, когда один обработчик привязан к нескольким компонентам, а в предлагаемом тобой варианте с TButton1 это невозможно.
> (много хочу, наверно, а ведь в KOL/MCK что-то подобное уже
> есть),

MCK послабее механизм, чем DFM.

to ors_archangel © (11.12.06 01:18) [114]:
>расширение описание - свойство добавить, поле,
То есть все-таки наследование. Я правильно понял? Или Вы знаете другой метод расширения "описания"? Так вот, теперь подумайте, что мы получим, если будем плодить наследников по каждому мелкому поводу. Сколько классов будет в приложении? Оправдано ли это будет?

>делегирование я понимаю только как множественную обработку событий
Делегирование - это передача части функций другому объекту. Все.

>с помощью делегатов
Это как в .net? Если да, то учтите, что дотнетовские делегаты - полные аналоги event-ов в VCL. Отличие только в мультикастинге, но это уже особенности библиотеки - в VCL мультикастинга не было изначально, а на существующий механизм его не прикрутить.

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

> [114] ors_archangel © (11.12.06 01:18)

> Я имел в виду только расширение описание - свойство добавить,
> поле

Это и есть то, для чего предназначено наследование. Посмотри в потрохах VCL, там повсеместно нечто подобное, например иерархия
TCustomMemoryStream
TMemoryStream
TResourceStream
Есть и другие примеры.

> [116] Cyrax © (11.12.06 01:30)

Просто он чайник, а не ламер, и понял, что для продолжения дискуссии надо подучить предмет. И очень хорошо, именно так из чайников вырастают мастера.

Какой смысл оформлять классы, не имеющие... Найти похожие ветки