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

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

какого-какого файла? :)

Сишного. Ибо в мире юникса все, что нельзя выразить в С - надо посылать лесом. Со всем уважением к Tk%)

> Сишного. Ибо в мире юникса все, что нельзя выразить в С - надо посылать лесом. Со всем уважением к Tk%)

Сам же только что сорсы читал. Си. Причём, следует заметить, без макросовой каши.

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

tcl - язык метапрограммирования. И писать на нем можно в любом стиле (хоть ооп, хоть фп). Так что, что там "снаружи" не важно. :)

Дык эти сырцы довольно объектные, в пределах допустимых сями. Модель, конечно, простенькая - но если хватает...

> Дык эти сырцы довольно объектные, в пределах допустимых сями. Модель, конечно, простенькая - но если хватает...

объектный != объектно-ориентированный

>> Во-вторых, раз "снаружи" этого не видно, значит с использованием этого набора виджетов _можно_ писать гуй без ооп.
> tcl - язык метапрограммирования. И писать на нем можно в любом стиле (хоть ооп, хоть фп). Так что, что там "снаружи" не важно. :)

На tcl/qt писать не так легко. Угадай из-за чего :)

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

Можно, конечно. Насчет "нужно" - уже не уверен. Приведешь названия тулкитов, написанных в не-ООП стиле (только не надо Fudgets, пожалуйста).

> если нет - тогда всё-таки к доктору, в Кащенко

Блин, да что ты так зациклился на психиатрии? Расскажзывай, тут все свои %)

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

> ты принципиально шлангуешь?

Ну кто бы говорил.

> фишка не в том, что он допускает, а в том, что оно там не нужно.

Критерий "нужности" - в студию, а то мы договоримся до Тьюринг-полного Брэйнфака.

> и что отсутствие там ООП даёт большую производительность работы и большую гибкость создаваемого GUI

Кто и как сравнивал?

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

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

Ч0рт, ты меня пугаешь O_O

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

Примитивность Tcl^W^WImpedance mismatch? :)

>tcl - язык метапрограммирования. И писать на нем можно в любом стиле (хоть ооп, хоть фп). Так что, что там "снаружи" не важно. :)

как раз-таки наоборот, только это и важно - то, что Tcl/Tk позволяет тебе писать GUI, используя объектно-базированный подход в связке с метапрограммированием и великолепной событийной системой

и получается, что GUI таким образом писать не только можно, но и намного удобней, чем с использованием ООП

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

> Копейка на connect(), полкопейки на model, треть копейки на view... Ряд сам просуммируешь?

Ты неявно полагаешь ряд бесконечным, и это мошенничество :)

> Tcl/Tk позволяет тебе писать GUI, используя объектно-базированный подход в связке с метапрограммированием и великолепной событийной системой

> и получается, что GUI таким образом писать не только можно, но и намного удобней, чем с использованием ООП

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

Я готов согласиться на любой вариант.

>> Копейка на connect(), полкопейки на model, треть копейки на view... Ряд сам просуммируешь?
> Ты неявно полагаешь ряд бесконечным, и это мошенничество :)
Мошенничество было б, если б я тебя заставил суммировать по континууму. А тут всего-то счётное множество :)

>Можно, конечно. Насчет "нужно" - уже не уверен. Приведешь названия тулкитов, написанных в не-ООП стиле (только не надо Fudgets, пожалуйста).

facepalm. опять? ты что, тоже потерял разницу между "писать в стиле А с помощью технологии Б" и "технология Б, реализованная в стиле А"? ну 3.14здец же какой-то, умные вроде бы люди

по существу - XPCE, REBOL/GUI, любой высокоуровневый GUI-движок для Haskell (тот же Phooey или FranTk)

>Кто и как сравнивал?

каждый, кто хоть раз писал на Tcl/Tk. секрета никто не делает. попробуй и сравни сам

>Примитивность Tcl^W^WImpedance mismatch? :)

излишняя высокоуровневость Qt. причём именно из-за ООП

> Я готов согласиться на любой вариант.
Если готов согласиться на "объектный" вариант, то возьми tk.

К слову, а оффтопичный winapi насколько объектно-ориентирован?

>Сишного. Ибо в мире юникса все, что нельзя выразить в С - надо посылать лесом. Со всем уважением к Tk%)

насчёт выразить в С - бред; но вообще я подумаю над задачкой

> каждый, кто хоть раз писал на Tcl/Tk. секрета никто не делает. попробуй и сравни сам

И главное не заменять это tkinter-ом.

Вполне себе. Хотя бы объектен.

Дык что - будет пример GUI API, который не О и не ОО (нет это не олимпийские кольца)?

>Кажется, начинает брезжить тусклый свет понимания :)

чего и кем? а то меня счас кондратий уже хватит, очевидные вещи-то доказывать

>Дык что - будет пример GUI API, который не О и не ОО (нет это не олимпийские кольца)?

http://haskell.org/haskellwiki/Phooey

http://haskell.org/FranTk/

пойдёт?

> Дык что - будет пример GUI API, который не О и не ОО (нет это не олимпийские кольца)?

tk. Даже если высосать из пальца^W сорса похожесть его на оо, его не видно. Потому что нет коллбеков и виртуальных функций, а есть замфкания и только они.

>> Можно, конечно. Насчет "нужно" - уже не уверен. Приведешь названия тулкитов, написанных в не-ООП стиле (только не надо Fudgets, пожалуйста).

> facepalm. опять? ты что, тоже потерял разницу между "писать в стиле А с помощью технологии Б" и "технология Б, реализованная в стиле А"?

Я потерял? O_O Ты спрашивал "можно ли написать GUI-библиотеку без ООП", я ответил. Ну перепутал немного с копипастом, уж извини.

> по существу - XPCE, REBOL/GUI, любой высокоуровневый GUI-движок для Haskell (тот же Phooey или FranTk)

Запомню. Но вот FranTk почему-то напоминает мне о Tk :D

>>Кто и как сравнивал?

>каждый, кто хоть раз писал на Tcl/Tk. секрета никто не делает. попробуй и сравни сам

Я првильно понимаю - органолептическое сравнение сильно разных по реализации тулкитов? "facepalm. ну 3.14здец же какой-то, умные вроде бы люди" (c) jtootf

И вообще... _конкретные_ претензии к ООП будут? Мне кажетя, всё сведется к hooks vs наследование.

кстати, а почему эта тема не в девеле? может стоило бы перенести? в толксы далеко не все ходят, а дискуссия-то интересная - по обоим направлениям

Не очень. Я там вижу понятие Виджета, что уже по сути является объектом.

> И вообще... _конкретные_ претензии к ООП будут? Мне кажетя, всё сведется к hooks vs наследование.

А претензий к ооп и нет. Есть претензии к его неоптимальному использованию.

>Я потерял? O_O Ты спрашивал "можно ли написать GUI-библиотеку без ООП", я ответил. Ну перепутал немного с копипастом, уж извини.

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

>Я првильно понимаю - органолептическое сравнение сильно разных по реализации тулкитов?

замер времени на решение задачи. сравнивал Qt и Tcl/Tk. что значит "органолептическое" - не понял

>И вообще... _конкретные_ претензии к ООП будут? Мне кажетя, всё сведется к hooks vs наследование

конкретные претензии: GUI на ООП выражается хреново :) ибо а) описание GUI должно быть декларативным (оно такое по природе вещей) б) описание событийной модели ООП не требует, оно как раз требует ФП (и Reactive тому - хорошая иллюстрация)

> Не очень. Я там вижу понятие Виджета, что уже по сути является объектом.

Из объектности не следует объектно-ориентированность.

>Не очень. Я там вижу понятие Виджета, что уже по сути является объектом.

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

>А претензий к ооп и нет

у меня - есть. но это тема для отдельного топика :) в этом и так уже слишком толсто

Сейчас времени нет. Вечером если не забуду - подумаю или нагуглю.

>> А претензий к ооп и нет

> у меня - есть. но это тема для отдельного топика :)

Да ладно, выкладывай здесь.

> в этом и так уже слишком толсто

А ты тонко :D

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

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

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

ну а полиморфизм ООП не требует, это самостоятельный и куда более низкоуровневый механизм

>Да ладно, выкладывай здесь.

топик прогнётся от количества НЕНАВИСТИ. ты и так уже меня боишься, не рискну продолжать :)

> топик прогнётся от количества НЕНАВИСТИ. ты и так уже меня боишься, не рискну продолжать :)

Просим! Просим!

P.S. (cast 'Absurd)

> И главное не заменять это tkinter-ом.

А в чем проблема с tkinter? Я когда начал изучать питон (сразу после tcl), мне tkinter тоже показался несколько странным (отовсюду уши tcl торчали). А сейчас уже так не кажется. И мне теперь удобней tk в питоне использовать. :) Самое главное - там tcl/tk *полностью* доступен. (можно даже несколько интерпретаторов tcl запустить)

>> Да ладно, выкладывай здесь.

> топик прогнётся от количества НЕНАВИСТИ.

Это типа реклама? :D

> ты и так уже меня боишься, не рискну продолжать :)

Я уже понял, что по HTTP ты мне ничего не сделаешь, и успокоился :) А вот _за_ тебя я всё еще тревожусь, нельзя же так НЕНАВИДЕТЬ какую-то концепцию :)

Кстати, св. троица "инкапсуляция, наследование и полиморфизм" - это ведь не догма. Мне кажется, что в Смолтоке не было нормальной инкапсуляции, где-то еще не было нормального наследования (только агрегациия). Вообще, ООП - это подмножество операций конструирования АТД. Убей меня бог, не могу понять, за что его ненавидеть.

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

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

Почему именно структурной составляющей? Хранение состояния, хранение значения --- как раз место применения инкапсуляции. И тут она рулит и педалит.

>> И главное не заменять это tkinter-ом.

> А в чем проблема с tkinter? Я когда начал изучать питон (сразу после tcl), мне tkinter тоже показался несколько странным (отовсюду уши tcl торчали).

В том и проблема, что там получится каша и тиклепитона.

> Вообще, ООП - это подмножество операций конструирования АТД. Убей меня бог, не могу понять, за что его ненавидеть.

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

>> Вообще, ООП - это подмножество операций конструирования АТД. Убей меня бог, не могу понять, за что его ненавидеть.

> Можно ненавидеть за то, что оно является мейнстримом,

Ну станет ФП мэйнстримом - его ненавидеть?

Ненавидеть мейнстрим - контрпродуктивно. Его надо использовать, по возможности эффективно (хотя это и не всегда возможно).

>> Можно ненавидеть за то, что оно является мейнстримом,
> Ну станет ФП мэйнстримом - его ненавидеть?

Выдёргивание фраз из контекста --- очень сильный ход. Почти такой же сильный, как и объявление оппонента быдлом.

Если потрудиться осилить абзац полностью, там написано, какое следствие этого мне не нравится. И таки да, если будут всё что ни попадя притягивать к фп, я тоже буду НЕНАВИДЕТЬ. :)

> Выдёргивание фраз из контекста --- очень сильный ход. Почти такой же сильный, как и объявление оппонента быдлом.

/me тщательно конспектирует

> да, если будут всё что ни попадя притягивать к фп, я тоже буду НЕНАВИДЕТЬ. :)

Вот видишь, ты всё понял и ответил.

>> да, если будут всё что ни попадя притягивать к фп, я тоже буду НЕНАВИДЕТЬ. :)
> Вот видишь, ты всё понял и ответил.

Ну то есть ты разрешаешь мне НЕНАВИДЕТЬ? ;)

> Ну то есть ты разрешаешь мне НЕНАВИДЕТЬ? ;)

А приписывание оппоненту фраз, которые он не говорил - это более сильный ход, чем обозвать былом, или менее? %)

>> Ну то есть ты разрешаешь мне НЕНАВИДЕТЬ? ;)
> А приписывание оппоненту фраз, которые он не говорил - это более сильный ход, чем обозвать былом, или менее? %)

Это был вопрос.

> Это был вопрос.

Это было бы вопросом, если бы не "то есть".

Но я разрешаю тебе ненавидеть ООП, не вопрос :)

> Но я разрешаю тебе ненавидеть ООП, не вопрос :)

Припрятал разрешение до лучших времён. А ещё за разрешениями на ненависть обращаться можно? :о)

> А ещё за разрешениями на ненависть обращаться можно? :о)

Бесплатна только первая доза :)