Абстрактное о ЯП для СУБД

> Да нет, это просто хотелка такая! Хочу рефакторинг. Хочу удобства для внесения изменений в код.

EXPLAIN не спасёт?

А при чем тут 1C?

Не очень понял, как спасет explain.

>> Ну и что? tcl/tk тоже ООП-нутый, только это не сразу видно:

>Бгг, где ты в tk увидел наследование? А инкапсуляцию? Полиморфизм есть, это да, но двух других слонов ооп не видно.

Внутри. Посмотри исходники tk, там всё есть.

>> Бгг, где ты в tk увидел наследование? А инкапсуляцию? Полиморфизм есть, это да, но двух других слонов ооп не видно.
> Внутри. Посмотри исходники tk, там всё есть.

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

> Ты давай сам показывай, а то гнилыми помидорами закидаем.

Упс. Не, тут я сливаю. (Ты в исходники tk заглядывал? Ну вот хоть здесь посмотри: http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkFrame.c?re... )

Так, первый помидор полетел.

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

>>В рамках проекта эти усложнения не нужны. Мне нужен был не мегауниверсальный фреймфорк, а средство решения конкретной задачи.
> Где в sql нужна "гибкость работы с типами"?
>> А чем в этом смысле sql лучше-хуже других языков?

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

Строка 38 - инкапсуляция!!!

А 34 и 107 - наследование.

> А 34 и 107 - наследование.

Это агрегация. Инкапсуляцию засчитываю.

107 - наследование точно. (обрати внимание на комментарий) Ну вот так вот наследование на С реализуется.

а строка 622 -- полиморфизм, лол.

>> А 34 и 107 - наследование.

> Это агрегация.

107 - это именно наследование: "* This must be the first element of the Labelframe".

или 177-280

> а строка 622 -- полиморфизм, лол.
а никто и не говорил про его отсутствие.

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

а вот теперь вопрос. Инкапсуляция в SQL очевидна. А где полиморфизм и наследование, это домены/внешние ключи?

>> Это агрегация.
> 107 - это именно наследование: "* This must be the first element of the Labelframe".

Я настаиваю на агрегации. С помощью неё можно много чего похожего на наследование. И они идут ноздря в ноздрю, пока не нужно вызвать метод, переопределённый в потомке.

FK правда больше на аггрегацию с миксинами смахивает

вот та строчка 622 -- это очевидно конструктор.
И то, что sizeof(Base)<=sizeof(Derived) тут не случайно.

> А при чем тут 1C?

Внутренний язык 1С -- дикая помесь сикля с бейсиком, причём на русском языке. Представляю там лямбды и замыкания...

APL туда надо, APL :))

> Не очень понял, как спасет explain.

Тогда объясните, что понималось под рефакторингом, применительно к сиклю.

Лямбда по-русски будет, очевидно, полная фита. В верхнем регистре.

ЗЫ См. происхождение слова "фитюк"

>>> Это агрегация.

>> 107 - это именно наследование: "* This must be the first element of the Labelframe".

> Я настаиваю на агрегации.

Ну еще бы - иначе придется признать ошибку :) Но комментарий недвусмысленно говорит - наследование.

Ну, например, возможность перетаскивать блоки кода с детекцией всех необходимых зависимостей, попыткой их разрешить и обращением к помощи (зала) программиста при невозможности оного.

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

Я не вижу там слова "наследование".

В любом случае снаружи унаследовать Button мы не сможем иначе как через агрегацию (как, собственно, делается в snit и megawidget).

> Ну, например, возможность перетаскивать блоки кода с детекцией всех необходимых зависимостей, попыткой их разрешить и обращением к помощи (зала) программиста при невозможности оного.

В той же 1С, чур меня... конструкторы вполне отсеивают эту потребность. Хотя мне и сейчас не понятно, для чего это нужно в голом сикле, неприкрытом хотя бы одной абстакцией над таблицами.

А про "снаружи" никто не говорил. Речь шла о реализации гуи без ооп. И привели в пример tcl/tk. А он оказался ООП-нутый.

> А про "снаружи" никто не говорил. Речь шла о реализации гуи без ооп. И привели в пример tcl/tk. А он оказался ООП-нутый.

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

Про абстракции - пожалуй, согласен. Их тоже нужно.

>А про "снаружи" никто не говорил. Речь шла о реализации гуи без ооп. И привели в пример tcl/tk. А он оказался ООП-нутый

ты тролль, лжец и девственник. реализация GUI на Tcl/Tk ни разу не использует ООП; реализация Tk в той или иной мере - да, однако даже школьнику понятно, что совсем оно там не обязательно

а если ты не видишь разницы между технологией и её реализацией - тебе к доктору

> реализация Tk в той или иной мере - да, однако даже школьнику понятно, что совсем оно там не обязательно

Даже школьнику понятно, что внутри Tk реализован в ОО-стиле. Докажи, что это возможно было по-другому - реализуй свой Tk :)

>Даже школьнику понятно, что внутри Tk реализован в ОО-стиле. Докажи, что это возможно было по-другому - реализуй свой Tk :)

это провокация

> Докажи, что это возможно было по-другому - реализуй свой Tk :)

С блекджеком, надеюсь?

>> Даже школьнику понятно, что внутри Tk реализован в ОО-стиле. Докажи, что это возможно было по-другому - реализуй свой Tk :)

> это провокация

Ха, а ты думал - в сказку попал? Есть Tk, внутри реализованный в ОО-стиле, а снаружи допускающий использование и без ОО (как и любой тулкит, кстати - двже на Qt можно писАть в процедурном стиле). Вот реальность, и никакие посылы к доктору это не изменят.

>> Докажи, что это возможно было по-другому - реализуй свой Tk :)

> С блекджеком, надеюсь?

С преферансом.

>> С блекджеком, надеюсь?
> С преферансом.
Преферанс объектно-ориентирован, так что не катит.

Тогда с низкоуровневым пасьянсом-косынкой.

> Преферанс объектно-ориентирован, так что не катит.

У тебя ООП-фобия, походу. Хочешь поговорить об этом? Хотя чего это я - ты же о ней и говоришь %)

> Есть Tk, внутри реализованный в ОО-стиле, а снаружи допускающий использование и без ОО (как и любой тулкит, кстати - двже на Qt можно писАть в процедурном стиле).

Да ладно-ка. Как там сигнал со слотом соединить, не вляпавшись в наследование и инкапсуляцию методов?

> У тебя ООП-фобия, походу. Хочешь поговорить об этом? Хотя чего это я - ты же о ней и говоришь %)

Я ещё боюсь голых женщин. Давай поговорим о голых женщинах :о)

> Как там сигнал со слотом соединить, не вляпавшись в наследование и инкапсуляцию методов?

Во-первых, "соединение сигнала со слотом" - это копейки, остальное можно писать в труЪ-процедурном стиле; во-вторых, однажды как-то же прицепили Qt к Си :)

А еще вроде ее прицепили к Хасеклю... или это был wx?

>Ха, а ты думал - в сказку попал? Есть Tk, внутри реализованный в ОО-стиле, а снаружи допускающий использование и без ОО (как и любой тулкит, кстати - двже на Qt можно писАть в процедурном стиле). Вот реальность, и никакие посылы к доктору это не изменят.

ещё раз - написать GUI можно (и нужно) без ООП. с этим ты согласен? если нет - тогда всё-таки к доктору, в Кащенко

следующий пункт - можно ли написать GUI-библиотеку без ООП? я - за то, что можно, однако удобного примера под рукой нет. провокация именно в этом и заключается - можно ведь и написать

>снаружи допускающий использование и без ОО (как и любой тулкит, кстати - двже на Qt можно писАть в процедурном стиле)

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

>А еще вроде ее прицепили к Хасеклю... или это был wx?

Qt и к Tcl прицепили. только сложность сцепления там несопоставимая с Tk. а знаешь почему? :)

>У тебя ООП-фобия, походу

у меня ООП-МДС. за неуместное использование хочется УБИВАТЬ

>Давай поговорим о голых женщинах :о)

начинай :)

>> Как там сигнал со слотом соединить, не вляпавшись в наследование и инкапсуляцию методов?

> Во-первых, "соединение сигнала со слотом" - это копейки, остальное можно писать в труЪ-процедурном стиле;
Копейка на connect(), полкопейки на model, треть копейки на view... Ряд сам просуммируешь?

> во-вторых, однажды как-то же прицепили Qt к Си :)
Сделать-то можно что угодно. Tk позволяет писать как тнб на душу положит, а qt лучше смотрится с ооп.

> провокация именно в этом и заключается - можно ведь и написать
Можно попросить накидать примерный драфт заголовочного файла? Хотя бы 20-30 строчек.