Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, minorlogic, Вы писали:
EC>>>А что с шаблонами не так?
M>>То что используемый контракт налагаемый на шаблонный класс нигде явно не выражен.
EC>Так консепты как раз эту задачу и решают или я что-то упустил?
Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.
Здравствуйте, minorlogic, Вы писали:
EC>>Так консепты как раз эту задачу и решают или я что-то упустил?
M>Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.
Почему частично? Чего не хватает для полного счастья кроме необязательности?
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, minorlogic, Вы писали:
EC>>>Так консепты как раз эту задачу и решают или я что-то упустил?
M>>Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.
EC>Почему частично? Чего не хватает для полного счастья кроме необязательности?
Здравствуйте, deniok, Вы писали:
EC>>Почему частично? Чего не хватает для полного счастья кроме необязательности?
D>Лично мне — изоморфизма Карри-Ховарда
и как долго тогда Комитет будет обсуждать аксиому выбора?
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, minorlogic, Вы писали:
EC>>>Так консепты как раз эту задачу и решают или я что-то упустил?
M>>Нет. Они частично пытаються ее решить. К сожалению или счастью , использование концептов необязательно.
EC>Почему частично? Чего не хватает для полного счастья кроме необязательности?
Явного указания програмистом что используемый класс реализует некий концепт.
типа
class Customer support refCountable;
где Customer внешний класс , support некое ключевое слово, и refCountable концепт. В данном случае на форме не настаиваю , важна идея явного указания потдержки классом концепта.
В идеале я бы хотел совместить наследование интерфейсов с данным механизмом. Все это источник многочисленных технических споров, возможно я к ним не готов.
[]
M>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.
Зачем лечить мифические болезни? Ты не думал, что эта кривость для создателей было то, что нужно? Чем плох пистолет по сравнению с автоматом? Видимо тем, что он решает те же задачи, но в других ситуациях.
Здравствуйте, Константин Л., Вы писали:
КЛ>Зачем лечить мифические болезни? Ты не думал, что эта кривость для создателей было то, что нужно? Чем плох пистолет по сравнению с автоматом? Видимо тем, что он решает те же задачи, но в других ситуациях.
Обожаю аналогии! Здесь уместнее будет не пистолет, а вилка. Ей тоже можно убить. Причем так как у нее 4 острых части, то теоритически она в 4 раза эффективнее любого пулемета .
КЛ>Меня иногда коробит "концептность" .net generics.
Хороший пример. Давай я тебе поясню на нем чем плохи шаблоны С++. Дженерики проектировались специалистами с серьезной мат.подготовкой. Они были продуманы, птестированы, подверглись крититике со стороны коммерческих программистов и в итоге были после доводки реализованы теми самыми коммерческими программистами. При этом учидывались следующие факторы:
1. Дженерики должны были обеспечивать параметрический полиморфизм (это же делают шаблоны).
2. Дженерики должны быть безопасны и просты в применении (этого у шаблонов нет... возможно концепту чуть поправят ситуцию, но устранить излишнюю сложность уже никогда не удастся).
3. Дженерики должны быть применимы только для обобщенного программирования (шаблоны же в виду излишней мощьности на сегодня часто применяются для метапрограммирования во время компиляции).
4. Дженерики не должны нарушать других систем динамической ОО-системы типов. Они обязаны поддерживать модульность и распространение в бинарных сборок (шаблоны С++ суность времени компиляции и их фактичесуки невозможно сделать модульными).
5. Дженерики должны поддерживаться Intellisense-ом в IDE (это тоже, в виду переусложныенности в полной мере шаблонам не доступно, причем в частности из-за пунткта 4).
В итоге мы имеем:
1. Шаблоны несомнее мощьнее дженериков, так как кроме параметрического полиморфизма они так же обеспечивают возможности метапрограммирования.
2. Шаблоны несомнее мощьнее дженериков, так как они производят прямые подстановки кода во время компиляции, что позволяет добитьсе большей эффективности кода.
3. Шаблоны несонменно переусложнены и разработка чего-то сложнее чем одноуровневые шаблоны доступна ограниченному (и довольно узкому) кругу лиц.
4. Шаблоны несомненно несовместимы с модульностью и динамикой.
5. Шаблоны слишком часто используются для решения задач на которые они не рассчитаны (метапрограммирование), и в то же время в языке почти нет других средств метапрограммирования (за исключением и препроцессора использование которого является так же багодромом).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>Зачем лечить мифические болезни? Ты не думал, что эта кривость для создателей было то, что нужно? Чем плох пистолет по сравнению с автоматом? Видимо тем, что он решает те же задачи, но в других ситуациях.
VD>Обожаю аналогии! Здесь уместнее будет не пистолет, а вилка. Ей тоже можно убить. Причем так как у нее 4 острых части, то теоритически она в 4 раза эффективнее любого пулемета .
Если мне надо кого-то заколбасить на званом ужине, я рассмотрю вилку как неплохое орудие убийства, особенно если я умею ей профессионально ообращаться.
КЛ>>Меня иногда коробит "концептность" .net generics.
VD>Хороший пример. Давай я тебе поясню на нем чем плохи шаблоны С++. Дженерики проектировались специалистами с серьезной мат.подготовкой. Они были продуманы, птестированы, подверглись крититике со стороны коммерческих программистов и в итоге были после доводки реализованы теми самыми коммерческими программистами. При этом учидывались следующие факторы:
С серьезной мат. подготовкой, понимаешь! Влад, хватит хрень всякую нести. Что там проектировать? Апполон 13? Какая еще мат. подготовка?
Если отбросить пыл, то никакая мат подготовка и коммерческость программистов еще ничего не гарантирует.
[]
Тут все правда. Но шаблоны это концептуально законченная идея. Нравится она тебе или minorlogic'у или не нравится — на ее законченность это не влияет.
Здравствуйте, Константин Л., Вы писали:
КЛ>Если мне надо кого-то заколбасить на званом ужине, я рассмотрю вилку как неплохое орудие убийства, особенно если я умею ей профессионально ообращаться.
Не. Я любитель. Есть люблю ей, а так — нет.
КЛ>С серьезной мат. подготовкой, понимаешь! Влад, хватит хрень всякую нести. Что там проектировать? Апполон 13? Какая еще мат. подготовка?
The PPG group at MSR Cambridge have been designing and prototyping support for "generics" in C# and the .NET Common Language Runtime. Generics are also known as polymorphism, parameterized types, or templates.
Особо обрати внимание на год.
Кстати, один из мужиков занимавшийся дженериками разработал F#.
КЛ>Если отбросить пыл, то никакая мат подготовка и коммерческость программистов еще ничего не гарантирует.
Это уже не совсем так. В МС взяли на работу многих исследователей. В том числе тех что создали Хаскель, F# и т.п.
КЛ>Тут все правда. Но шаблоны это концептуально законченная идея. Нравится она тебе или minorlogic'у или не нравится — на ее законченность это не влияет.
Шаблоны созданы "из лучших побуждений" человеком который не имел достаточно полготовки. Их правда, что делали для того чтобы "сделать vector<T>". Ошибок было сделано уйма.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>Если мне надо кого-то заколбасить на званом ужине, я рассмотрю вилку как неплохое орудие убийства, особенно если я умею ей профессионально ообращаться.
VD>Не. Я любитель. Есть люблю ей, а так — нет.
КЛ>>С серьезной мат. подготовкой, понимаешь! Влад, хватит хрень всякую нести. Что там проектировать? Апполон 13? Какая еще мат. подготовка?
VD>
The PPG group at MSR Cambridge have been designing and prototyping support for "generics" in C# and the .NET Common Language Runtime. Generics are also known as polymorphism, parameterized types, or templates.
Тут я, видимо, должен упасть под стол от крутости чуваков. Не путай концепцию с имплементацией. Концепция проста до ужаса, особенно когда до тебя делали такое-же или почти такое же. Причем и в одиночку. Я бы удивился, если бы вся эта толпа (или сколько их там) изобрела вторые c++ templates.
VD>Особо обрати внимание на год. VD>Кстати, один из мужиков занимавшийся дженериками разработал F#.
F# теперь супер мега язык? "Разработал"... Звучит то как.
КЛ>>Если отбросить пыл, то никакая мат подготовка и коммерческость программистов еще ничего не гарантирует.
VD>Это уже не совсем так. В МС взяли на работу многих исследователей. В том числе тех что создали Хаскель, F# и т.п.
Отлично, но не стоит хвастаться, что дженерики сделали супер математики. Я бы на их месте это за заслугу не считал. В академическом плане.
КЛ>>Тут все правда. Но шаблоны это концептуально законченная идея. Нравится она тебе или minorlogic'у или не нравится — на ее законченность это не влияет.
VD>Шаблоны созданы "из лучших побуждений" человеком который не имел достаточно полготовки. Их правда, что делали для того чтобы "сделать vector<T>". Ошибок было сделано уйма.
Достаточно подготовки? Не смеши. Есть только 2 концепции, которые отличают templates от generics: констрейнты, сохранение "исходного" кода для последующей кодогенерации. И все. Ничего революционного. Сомневаюсь, что Страуструп не рассматривал эти фичи при проектировании. Просто он их сознательно выкинул.
ПС: косяки в темплейтах есть. Но они скорее сишные, чем темплейтные. То есть атавизмы. Концепты поправят констрейнты. Со вторым ничего делать просто не надо.
Здравствуйте, VladD2, Вы писали:
VD>Хороший пример. Давай я тебе поясню на нем чем плохи шаблоны С++. Дженерики проектировались специалистами с серьезной мат.подготовкой. Они были продуманы, птестированы, подверглись крититике со стороны коммерческих программистов и в итоге были после доводки реализованы теми самыми коммерческими программистами.
Только ни одному из этих горе-специалистов не хватило сообразиловки сделать констрейнты на new с параметрами, или например простейший оператор сложения. Вот и появляются потом извраты с активатором или рефлекшеном Не говоря уже о такой маленькой но жутко полезной фиче как type alias.
В общем, косяков у генериков тоже более чем достаточно.
Здравствуйте, Andrei F., Вы писали:
AF>Только ни одному из этих горе-специалистов не хватило сообразиловки сделать констрейнты на new с параметрами, или например простейший оператор сложения. Вот и появляются потом извраты с активатором или рефлекшеном
Это проблемы не дженериков, а системы типов дотнета. Создание объектов без передачи параметров тоже реально превращается в вызво активатора (что, естестенно не быстро).
Зато в языке есть функционаьный тип (впрочем тоже не без косяков) и интерфейсы которые позволяют передавать в методы обобщенные ссылки на фукнции и классы. Это позволяет обходить ограничения не превращая дженерики в чисто текстуальные сущности.
Это просто другой подход. Тебе не нужно позволять вызвать у типов операторы и тому подобное. Вместо этого ты можешь просто передать нужные фунции или интерфейсы в качестве параметров.
AF>Не говоря уже о такой маленькой но жутко полезной фиче как type alias.
Это вообще проблема Шарпа. У дженирикам никаким боком не относящаяся. В тот же Немерле оные есть не смотря на полную поддержку дженириков.
AF>В общем, косяков у генериков тоже более чем достаточно.
Ты путашь косяки дженериков и того для чего они реализованы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это проблемы не дженериков, а системы типов дотнета. Создание объектов без передачи параметров тоже реально превращается в вызво активатора (что, естестенно не быстро).
Да без разницы, что там внутри. Проблема в том, что я не могу просто написать new T(var1, var2), а вместо этого мне приходится черт-те что городить, чтобы решить эту крайне простую задачу. Попробуй ка без MSDN вспомни, какие параметры здесь надо написать, чтобы сделать то же самое через явный вызов активатора?
VD>Зато в языке есть функционаьный тип (впрочем тоже не без косяков) и интерфейсы которые позволяют передавать в методы обобщенные ссылки на фукнции и классы. Это позволяет обходить ограничения не превращая дженерики в чисто текстуальные сущности.
А не подскажешь, как получить делегат на оператор сложения двух чисел? Почему они не сделали интерфейс IAddable, на самый уж худой конец?
И почему нельзя записать в констрейнте System.Enum? Он то кому мог помешать?
VD>Это просто другой подход. Тебе не нужно позволять вызвать у типов операторы и тому подобное. Вместо этого ты можешь просто передать нужные фунции или интерфейсы в качестве параметров.
Здравствуйте, Andrei F., Вы писали:
AF>Да без разницы, что там внутри. Проблема в том, что я не могу просто написать new T(var1, var2), а вместо этого мне приходится черт-те что городить, чтобы решить эту крайне простую задачу. Попробуй ка без MSDN вспомни, какие параметры здесь надо написать, чтобы сделать то же самое через явный вызов активатора?
Согласен, неудобно. Но не смертельно. Тут нужно использовать фабрики классов или фабричные метода (инициализируемые лямбдами).
AF>А не подскажешь, как получить делегат на оператор сложения двух чисел?
Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int".
В менее правильных языках это будет выглядить так: "(x, y) => x + y".
AF> Почему они не сделали интерфейс IAddable, на самый уж худой конец?
Там начинаются проблемы с полиморфизмом. Ведь по уму нужно будет делать интерфейсы для всех сочетаний типов (IAddable<int, double>, IAddable<short, int>, ...), а это вызвает две проблемы 1) комбинаторный врыв, 2) невозможность расширения уже определенных интерфейсов.
Правильное решение было придумано в Хаскеле. Там придумали классы типов. Это что-то типа интерфейсов, но их не реализуют в тиах, а воплощают для типов. Если, например, у тебя есть типы int и double и теб нужно применить их где-то где поддерживается класс типов Addable, то тбе достаточно создать воплощение Addable для Addable<int, double> (псевда-синтаксис, аля Шарп).
AF>И почему нельзя записать в констрейнте System.Enum? Он то кому мог помешать?
В Немерле это допустимо. Только я никогда не пользовался. Нет нужды, как-то.
VD>>Это просто другой подход. Тебе не нужно позволять вызвать у типов операторы и тому подобное. Вместо этого ты можешь просто передать нужные фунции или интерфейсы в качестве параметров.
AF>Это не подход, это костыль. Причем кривой.
Нет. Это как раз отличный подход. Они универсально действует везде, а не только тут. На его основе можно офигительно просто писать программы кторые при этом будут очень хорошо читаться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei F., Вы писали:
AF>>А не подскажешь, как получить делегат на оператор сложения двух чисел?
VD>Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int". VD>В менее правильных языках это будет выглядить так: "(x, y) => x + y".
У мсье есть некий "истинный критерий святой правильности"?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Andrei F., Вы писали:
AF>>>А не подскажешь, как получить делегат на оператор сложения двух чисел?
VD>>Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int". VD>>В менее правильных языках это будет выглядить так: "(x, y) => x + y".
К>У мсье есть некий "истинный критерий святой правильности"?
А ты до сих пор этого не знал?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, VladD2, Вы писали:
К>>У мсье есть некий "истинный критерий святой правильности"?
E>А ты до сих пор этого не знал?
Ну может забыл и ещё люди меняются (лучше, конечно, когда в положительную сторону).
Здравствуйте, VladD2, Вы писали:
VD>Согласен, неудобно. Но не смертельно. Тут нужно использовать фабрики классов или фабричные метода (инициализируемые лямбдами).
VD>Подскажу: "_ + _". Его тип будет выведен в автомате. Если нужно именно целых, то можно так: "_ _ : int + _ : int". VD>В менее правильных языках это будет выглядить так: "(x, y) => x + y".
костыли, костыли, костыли....
Что еще хуже, в отличие от плюснутых шаблонов никакая оптимизация здесь работать не будет, и в результате получится деградация производительности во многие разы на совершенно ровном месте.
VD>Там начинаются проблемы с полиморфизмом. Ведь по уму нужно будет делать интерфейсы для всех сочетаний типов (IAddable<int, double>, IAddable<short, int>, ...), а это вызвает две проблемы 1) комбинаторный врыв, 2) невозможность расширения уже определенных интерфейсов.
Ну например, для интерфейса IConvertible им эти проблемы почему-то не помешали. А здесь сделать то же самое — ну никак
В конце концов, можно было определить только версию интерфейса с аргументом того же типа, что и сам объект. Так они даже и этого не сделали.
VD>Нет. Это как раз отличный подход. Они универсально действует везде, а не только тут. На его основе можно офигительно просто писать программы кторые при этом будут очень хорошо читаться.
офигительно просто — это если я мог бы делать так:
T var1, var2;
// .......
T res = var1 + var2;
А когда вместо этого мне приходится плясать с бубном, чтобы просто сложить два числа, то это хрень полная, а не "отличный подход"
.
Не говоря уже о такой маленькой но жутко полезной фиче как type alias.
Почему они не сделали интерфейс IAddable, на самый уж худой конец?
