Здравствуйте, lazy/cjow/rhrr, Вы писали:
LCR>Среди выигрышей: LCR>1. определение функций, которые выполняют общие трансформации кода работающие для любых объектов (рефлекшн, рантайм-макросы)
Generic-функции.
LCR>2. определение функций, принимающих любой объект или последовательность объектов (например, логгер, Runnable)
И чо они будут делать с "любым объектом"? А вот Runnable — это уже не любой объект.
LCR>3. определение функций, возвращающих любой объект (например фабрики, ioc контейнеры)
Возврат любого объекта также бессмысленен. Нужен хотя бы интерфейс.
LCR>При достаточно развитой системы типов, некоторые из определений возможно бывает написать без object, используя разные продвинутые конструкции (см. например опредление функции map в Scala), но в общем случае нет.
В общем случае базовый предок не нужен.
LCR>Также из-за перегрузки становится невозможным описать тип "функция, принимающая любое количество любых аргументов", вместо этого в библиотеках постоянно фигурируют fun(a1); fun(a1, a2); ... fun(a1, a2, ..., a100500), я нахожу этот момент крайне неудобным.
А что функция будет делать с любыми объектами? Вызывать для них метод ToString? ИМХО, натянутый пример, особенно если учесть, что объект может иметь несколько строковых представлений.
LCR>Какое это имеет отношение к топику? А такое, что понятие "список аргументов функции" не является объектом, и это порождает определённые неудобства, которые вполне реальные
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, A13x, Вы писали:
A>>я считаю, что базовый класс необходим
MTD>Ты уверен, что кастрюля и ворона имеют одного предка?
смотря что ты моделируешь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, MTD, Вы писали:
MTD>>Здравствуйте, A13x, Вы писали:
A>>>...
MTD>>В новом языке не надо делать общий базовый класс — это просто глупо. Пусть программист осознанно обогащает свои классы реализуя необходимые интерфейсы.
A>Это спорное утверждение
A>.... но все же я считаю, что базовый класс необходим, но только с одним методом — getClass() или getTypeMirror()...
необходим метод Destroy() (деструктор)
зело полезен для написания всевозможных менеджеров/кэшей/IPC...
Всё сказанное выше — личное мнение, если не указано обратное.
AlexRK,
LCR>>Среди выигрышей: LCR>>1. определение функций, которые выполняют общие трансформации кода работающие для любых объектов (рефлекшн, рантайм-макросы) ARK>Generic-функции.
Определённые исследования ведутся в области typesafe макросов, конечно, но пока то, что я видел функции-трансформаторы имеют слишком дикую сигнатуру и делать так можно только в простых случаях. Generics слишком тощие, чтобы осилить Динамические прокси, АОП, сериализаторы/десериализаторы делаются и уж тем более кодогенерацию.
LCR>>2. определение функций, принимающих любой объект или последовательность объектов (например, логгер, Runnable) ARK>И чо они будут делать с "любым объектом"? А вот Runnable — это уже не любой объект. LCR>>3. определение функций, возвращающих любой объект (например фабрики, ioc контейнеры) ARK>Возврат любого объекта также бессмысленен. Нужен хотя бы интерфейс.
Когда ты просишь у меня "что они будут делать...", ты пытаешься вытащить из меня информацию о поведении. Никакой информации нет.
Runnable — пример, когда можно сделать только одно, довольно слабое предполжение о поведении. Проблемы те же.
Если ты вернёшь "хотя бы интерфейс" из своего IOC контейнера, ты тем самым автоматически сделаешь невозможным работу с объектами, которые не реализуют этот интерфейс. Это породит ситуацию, что как только я захочу использовать твой контейнер, я должен все объекты пометить этим интерфейсом. Это неудобно, и поэтому я буду использовать другой.
LCR>>Также из-за перегрузки становится невозможным описать тип "функция, принимающая любое количество любых аргументов", вместо этого в библиотеках постоянно фигурируют fun(a1); fun(a1, a2); ... fun(a1, a2, ..., a100500), я нахожу этот момент крайне неудобным. ARK>А что функция будет делать с любыми объектами? Вызывать для них метод ToString? ИМХО, натянутый пример, особенно если учесть, что объект может иметь несколько строковых представлений.
Опять попытка вытянуть информацию о поведении. Ложки нет!
LCR>>Какое это имеет отношение к топику? А такое, что понятие "список аргументов функции" не является объектом, и это порождает определённые неудобства, которые вполне реальные
ARK>Какие например?
Здравствуйте, lazy/cjow/rhrr, Вы писали:
LCR>Generics слишком тощие, чтобы осилить Динамические прокси, АОП, сериализаторы/десериализаторы делаются и уж тем более кодогенерацию.
Эм... а что, общий базовый тип Object это все осиливает?
Вроде разговор был про другое...
LCR>Когда ты просишь у меня "что они будут делать...", ты пытаешься вытащить из меня информацию о поведении. Никакой информации нет. LCR>Runnable — пример, когда можно сделать только одно, довольно слабое предполжение о поведении. Проблемы те же.
Прошу прощения, ничего не понял.
LCR>Если ты вернёшь "хотя бы интерфейс" из своего IOC контейнера, ты тем самым автоматически сделаешь невозможным работу с объектами, которые не реализуют этот интерфейс. Это породит ситуацию, что как только я захочу использовать твой контейнер, я должен все объекты пометить этим интерфейсом. Это неудобно, и поэтому я буду использовать другой.
По-моему, это рассуждение из серии "когда я задаю тип параметра функции, то я автоматически делаю невозможным вызов этой функции с аргументом другого типа, это неудобно".
Да, если контейнер возвращает интерфейс, то логично, что объект _должен_ его реализовать. Статическая типизация, однако.
LCR>Опять попытка вытянуть информацию о поведении. Ложки нет!
И опять не понял. Так что все же функция будет делать с "любыми объектами"?
LCR>Реализуй мне класс Tuple<..>
А может реализовать класс Class или класс Struct?
Тупл должен быть первоклассной сущностью, без поддержки компилятора он будет ужасно коряв. А раз так, нет необходимости иметь его описание на языке.
А других, более жизненных, примеров нет?
Здравствуйте, AlexRK, Вы писали:
LCR>>Опять попытка вытянуть информацию о поведении. Ложки нет! ARK>И опять не понял. Так что все же функция будет делать с "любыми объектами"?
Биндинг она динамический будет делать, допустим.
Reactive.bind(someFunction,functionArg1, functionArg2, functionArgN). someFunction — функция с N аргументами. Аргументы — либо "аргументы" функции, либо "реактивные" значения (могут изменятсья) с типом Reactive<T>. Результат бинда — значение типа Reactive<ReturnTypeOf<someFunction>>. Функция bind — одна. Макросами реализовывать не предлагать — не интересно. Да и обходить плохую систему типов языка макросами — чит.
Из подобных вариантов — связывание функции с аргументами (почти карринг, удобно в качестве слушателей на разные события подвешивать), универсальная обертка для отлова исключений, произошедших в функции (да, одна функция возвращающая "любую функцию"), частичное применение функции (для языков без каррированных изначально функций).
В конце концов функция может просто игнорировать свои аргументы. Это тоже периодически нужно (особенно если какой-нибудь сторонний фреймворк подсовывает ненужные аргументы).
Здравствуйте, iLikeCookies, Вы писали:
LC>Здравствуйте, MTD, Вы писали:
MTD>>В новом языке не надо делать общий базовый класс — это просто глупо. Пусть программист осознанно обогащает свои классы реализуя необходимые интерфейсы.
LC>Ага, конечно! Все кругом дураки, один MTD у нас самый умный, надо было у него спросить создателям Java/.NET. Как домашнее задание, предлагаю подумать на тему, почему все современные языки делают именно один общий базовый класс. Еще предлагаю подумать в качестве подсказки на тему, почему в C++, где нет единого общего корня, разные библиотеки так или иначе создают один базовый класс и какие недостатки у такого подхода.
С++, во-первых, появился после языков, в которых был общий предок для всего. Так что мимо.
Во-вторых, не считая уже упомянутой STL, вот есть коллекция из почти полутора сотен С++ библиотек — называется Boost. Покажи мне, где там библиотеки "так или иначе создают один базовый класс". (Подсказка 1 — в С++ есть шаблоны, так что общий базовый класс нафиг не нужен. Подсказка 2 — шаблоны обычно пишут так, чтоб они работали и со встроенными типами вроде int тоже.)
Здравствуйте, maxkar, Вы писали:
ARK>>И опять не понял. Так что все же функция будет делать с "любыми объектами"?
M>Биндинг она динамический будет делать, допустим.
M>Reactive.bind(someFunction,functionArg1, functionArg2, functionArgN). someFunction — функция с N аргументами. Аргументы — либо "аргументы" функции, либо "реактивные" значения (могут изменятсья) с типом Reactive<T>. Результат бинда — значение типа Reactive<ReturnTypeOf<someFunction>>. Функция bind — одна. Макросами реализовывать не предлагать — не интересно. Да и обходить плохую систему типов языка макросами — чит.
Так все равно тут общий предок не нужен, просто это должна быть генерик-функция. Это если рассматривать только момент с "любыми объектами", не касаясь другого вопроса — произвольного количества аргументов, который, на мой взгляд, очень сомнителен сам по себе.
Здравствуйте, AlexRK, Вы писали:
LC>>Как домашнее задание, предлагаю подумать на тему, почему все современные языки делают именно один общий базовый класс. ARK>Я считаю, что это неправильное решение.
А обосновать?
LC>>Еще предлагаю подумать в качестве подсказки на тему, почему в C++, где нет единого общего корня, разные библиотеки так или иначе создают один базовый класс и какие недостатки у такого подхода. ARK>Ну вот пусть и создают базовый класс там, где он нужен, а в язык его пихать зачем?
Короткий ответ, потому что на практике это очень удобно. Длинный ответ писать лень.
Здравствуйте, iLikeCookies, Вы писали:
EP>>Где, например, в STL единый базовый класс? LC>STL написана в функциональном стиле.
Что ты понимаешь под функциональным стилем (учитывая такие вещи как std::sort, std::vector и т.п.)?
То что используются функции высших порядков?
Или то что std::sort не засунута в класс и работает по чётным и нечётным?
Какие именно свойства стиля, о котором ты говоришь, позволяют обходится без общего корня?
И чем, по-твоему, такой стиль хуже стиля для которого общие корни нужны?
Evgeny.Panasyuk,
EP>>>Где, например, в STL единый базовый класс? LC>>STL написана в функциональном стиле.
EP>Что ты понимаешь под функциональным стилем (учитывая такие вещи как std::sort, std::vector и т.п.)? EP>То что используются функции высших порядков? EP>Или то что std::sort не засунута в класс и работает по чётным и нечётным?
EP>Какие именно свойства стиля, о котором ты говоришь, позволяют обходится без общего корня? EP>И чем, по-твоему, такой стиль хуже стиля для которого общие корни нужны?
Параметрический полиморфизм и классы типов позволяют вполне чудесно обходиться без общего корня. Но параметрический полиморфизм очень непросто склеить с ООП, где уже присутствует сабтайпинг полиморфизм. Плюс, параметрический полиморфизм — это фича в основном компилятора, а сабтайпинг полиморфизм — фича главным образом рантайма. Отсюда, в частности, отличия и сильные-слабые стороны.
Функциональный стиль ничем не хуже ООП-шного стиля, однако я не берусь сейчас определять это отношение "хуже-лучше". Примем на данный момент, что такой стиль — просто другой, для написания программ в таком стиле C++ подходит довольно хреновенько, Java совсем уныло выглядит, C# несколько лучше.
Почему шаблоны C++ являются плохой эмуляцией параметрического полиморфизма? Очень легко:
template <typename T> T id(T x){ return x; }
template <typename T> T plus(T x){ return x + x; }
в C++ных терминах тип у id и plus одинкаовый. Однако в терминах языка с правильной системой типов типы этих функций кардинально различаются:
Здравствуйте, iLikeCookies, Вы писали:
LC>Здравствуйте, AlexRK, Вы писали:
LC>>>Как домашнее задание, предлагаю подумать на тему, почему все современные языки делают именно один общий базовый класс. ARK>>Я считаю, что это неправильное решение.
LC>А обосновать?
Бесполезная вещь, способствует понижению качества кода из-за необходимости кастов.
LC>>>Еще предлагаю подумать в качестве подсказки на тему, почему в C++, где нет единого общего корня, разные библиотеки так или иначе создают один базовый класс и какие недостатки у такого подхода. ARK>>Ну вот пусть и создают базовый класс там, где он нужен, а в язык его пихать зачем?
LC>Короткий ответ, потому что на практике это очень удобно. Длинный ответ писать лень.
Лично я на практике особого удобства от этого не вижу. А вижу спроектированные через зад библиотеки, требующие во всех местах кастов от объекта к чему-то.
Здравствуйте, AlexRK, Вы писали:
MTD>>>Ты уверен, что кастрюля и ворона имеют одного предка? LC>>Имеют, они оба материальные объекты реального мира. Они даже имеют общие атрибуты, такие как вес, плотность итд. ARK>Тогда надо создавать предка "Материальный объект реального мира" и наследовать от него кастрюлю с вороной. А глобальный общий предок не нужен.
Это все словоблудие, мы ж тут вроде все инженеры собрались, тут вопрос другой, насколько удобен и наиболее подходит этот самый подход. Почему в каком либо языке или среде сделано так или иначе, нужно такой вопрос не отрываясь от исторических факторов, что повлияли на тот или иной выбор.
Здравствуйте, jazzer, Вы писали:
J>С++, во-первых, появился после языков, в которых был общий предок для всего. Так что мимо.
Да неужели? .NET/Java появились позже C++. Также, скорее всего тут нужно было сохранять обратную совместимость с языком С.
J>Во-вторых, не считая уже упомянутой STL, вот есть коллекция из почти полутора сотен С++ библиотек — называется Boost. Покажи мне, где там библиотеки "так или иначе создают один базовый класс". (Подсказка 1 — в С++ есть шаблоны, так что общий базовый класс нафиг не нужен. Подсказка 2 — шаблоны обычно пишут так, чтоб они работали и со встроенными типами вроде int тоже.)
Насчет Boost не знаю, но STL написана в функциональном стиле. Также я тут уже приводил примеры библиотек с общим предком: MFC — CObject, COM/ATL/WTL — IUnknown, Qt — QObject итд.
Также, вспоминая те годы, когда я работал C++ программистом занимался интеграцией разработок нескольких наших отделов, где в каждом отделе своя иерархия классов. Вот где действительно был трэш, угар и содомия. Я сам лично вообще противник наследования реализации, композиция — наше все!
Здравствуйте, iLikeCookies, Вы писали:
LC>Ага, конечно! Все кругом дураки, один MTD у нас самый умный
Давай без эмоций?
LC>надо было у него спросить создателям Java/.NET.
Java вообще сконструирована не самым удачным образом, почему разработчики C# удачно улучшив во многих местах Java оставили косяк с общим предком не знаю
LC>Как домашнее задание, предлагаю подумать на тему, почему все современные языки делают именно один общий базовый класс.
Это какие?
LC>Еще предлагаю подумать в качестве подсказки на тему, почему в C++, где нет единого общего корня, разные библиотеки так или иначе создают один базовый класс и какие недостатки у такого подхода.
Чаще всего эти библиотеки создавались тогда, когда на С++ еще не умели программировать (компиляторы были плохими) и тащили туда свои привычки из других языков.
Здравствуйте, iLikeCookies, Вы писали:
LC>Здравствуйте, jazzer, Вы писали:
J>>С++, во-первых, появился после языков, в которых был общий предок для всего. Так что мимо.
LC>Да неужели? .NET/Java появились позже C++. Также, скорее всего тут нужно было сохранять обратную совместимость с языком С.
Smalltalk
Никакой обратной совместимости с Си в плане классов быть не может в принципе, потому что там классов нету. Не с чем совместимость обеспечивать. Так что можно было и с общим классом придумать, и без него. Спасибо, Бьярне, что избавил нас от этой напасти!
J>>Во-вторых, не считая уже упомянутой STL, вот есть коллекция из почти полутора сотен С++ библиотек — называется Boost. Покажи мне, где там библиотеки "так или иначе создают один базовый класс". (Подсказка 1 — в С++ есть шаблоны, так что общий базовый класс нафиг не нужен. Подсказка 2 — шаблоны обычно пишут так, чтоб они работали и со встроенными типами вроде int тоже.)
LC>Насчет Boost не знаю, но STL написана в функциональном стиле. Также я тут уже приводил примеры библиотек с общим предком: MFC — CObject, COM/ATL/WTL — IUnknown, Qt — QObject итд.
COM — это бинарный протокол, а не библиотека, так что мимо. А остальные (MFC, Qt) — ну да, целых две, по сравнению с полутораста библиотеками Boost.
Да даже и в MFC, например, CString не наследовался от CObject. Так что CObject не является универсальным базовым классом, в отличие от Java, в которой java.lang.String — наследница java.lang.Object.
LC>Также, вспоминая те годы, когда я работал C++ программистом занимался интеграцией разработок нескольких наших отделов, где в каждом отделе своя иерархия классов. Вот где действительно был трэш, угар и содомия. Я сам лично вообще противник наследования реализации, композиция — наше все!
Не, если ты работал на С++ в 90-х, когда под ООП в С++ подразумевали сплошную виртуальщину и развесистые иерархии в стиле Smalltalk (типа MFC), то да. Только вот мы уже не то что в следующем десятилетии — через десятилетие живем
Здравствуйте, iLikeCookies, Вы писали:
LC>Это все словоблудие, мы ж тут вроде все инженеры собрались, тут вопрос другой, насколько удобен и наиболее подходит этот самый подход.
Вопрос удобства весьма субъективен. Кому-то и за типами следить неудобно.
А из измеряемых величин вполне можно выделить "число кастов от предка к потомку", которое общий базовый тип очевидно увеличивает, что плохо.
О наличии каких-либо преимуществ у общего базового типа в языке с хорошими генериками мне неизвестно (по-моему, таких преимуществ нет).
LC>Почему в каком либо языке или среде сделано так или иначе, нужно такой вопрос не отрываясь от исторических факторов, что повлияли на тот или иной выбор.
Ну, исторические факторы это другой вопрос. Мы же говорим об общей идеологии, разве нет?
Если в языке нет функционального типа, то остается использовать указатели. Из этого не следует, что указатели на функции — это хорошо. Это просто неизбежное зло, если мы хотим программировать на таком языке. ИМХО, с базовым типом то же самое — это признак недодуманности дизайна языка, закрывающий либо какие-то дырки в этом самом дизайне, либо legacy-проблемы.
Jack128,
LCR>>Почему шаблоны C++ являются плохой эмуляцией параметрического полиморфизма? Очень легко: LCR>>
LCR>>template <typename T> T id(T x){ return x; }
LCR>>template <typename T> T plus(T x){ return x + x; }
LCR>>
LCR>>в C++ных терминах тип у id и plus одинкаовый. J>Разве в С++ у id и plus есть тип?? это же шаблоны.
А, я понял, что так развеселило MTD и jazzer-а. У шаблонных функций (и классов) C++-ного типа нет, пока он не инстанцирован — это безтиповая символьная конструкция. Просто чтобы показать кусок от параметрического полиморфизма, доступный в C++, мне нужно установить в соответствие между обобщённым типом в ML и его аналогом в определениях выше. Так что аналогом типа a->a является... ну штуковина T (*fn)(T) для шаблонов.
Может эта штуковина имеет какое-то устоявшееся название, я не в курсе.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Лично я на практике особого удобства от этого не вижу. А вижу спроектированные через зад библиотеки, требующие во всех местах кастов от объекта к чему-то.
