Вышла очередная версия языка программирования D

> Так может переориентироваться на GTK и добавить в Glade поддержку D?

Используемый мной xml формат оказался подозрительно похож на формат glade. А gtkd - на fltk4d. Если ты готов помочь, можно попробовать. Самому разбираться в С/С++ меня не тянет.

gtkd - обьектно-ориентированная обертка для gtk на D: http://www.dsource.org/projects/gtkd

Массового применения у этого языка не будет. Там, где нужно системное и низкоуровневое программирование, хорошо подходит C/C++. Для высокоуровнего программирования - гораздо удобнее платформенные языки, такие как Java/C#

>Там, где нужно системное и низкоуровневое программирование, хорошо подходит C/C++.

А чем D для системного программирования хуже C++?

>Для высокоуровнего программирования - гораздо удобнее платформенные языки, такие как Java/C#

А чем D для высокоуровневого программирования хуже Java/C#? Я ещё понял бы, если б был приведён пример Python... :)

KRoN73, прочитал мои мысли. :) anonimuos, обоснуй!

> Для высокоуровнего программирования - гораздо удобнее платформенные языки, такие как Java/C#

Я так понимаю, имелось ввиду кросс-платформенные? Или VM?

Java удобнее, если проц и память не жалко. Опять таки: http://shootout.alioth.debian.org/ Видим, что в среднем D на 58% быстрее и в 6.8 раз меньше, чем java, несмотря на сборщик мусора. Сказывается отсутствие VM. А C++ imho не для высокоуровневого программирования. Просто раньше ничего лучше небыло.

> Там, где нужно системное и низкоуровневое программирование, хорошо подходит C/C++

Системное программирование - такая штука. Язык для него либо подходит, либо нет. D is a systems programming language. Только писать и читать код на нем приятнее, чем на C/C++. C/C++ хорошо подходит, но мог бы подходить еще лучше.

>А чем D для системного программирования хуже C++?

Тем, что молод, нет хороших сред разработки, нельзя напрямую использовать библиотеки, написанные на C++. Есть опасность, что язык черезмерно усложнят. Думаю Java или .NET залезут во все щели раньше, что люди созреют использовать D

>А чем D для высокоуровневого программирования хуже Java/C#? Я ещё понял бы, если б был приведён пример Python... :)

D хуже отсутствием платформы. Java/C# я привёл в пример как нединамичные языки

>Я так понимаю, имелось ввиду кросс-платформенные? Или VM?

Именно платформа, как JavaEE и .NET, т.е. кроме языка, большой набор стандартных библиотек и средств реализации типичных задач. Если такого не будет, каждый будет создавать свой велосипед

>Java удобнее, если проц и память не жалко. Опять таки: http://shootout.alioth.debian.org/ Видим, что в среднем D на 58% быстрее и в 6.8 раз меньше, чем java, несмотря на сборщик мусора. Сказывается отсутствие VM.

Это хорошо, но, думаю что недостаточно для превосходства над Java

> нет хороших сред разработки

Descent из svn. На оф. сайте все сказано. http://www.dsource.org/projects/descent Последнее обновление исходников - 11 часов назад. После окончательного вылизывания семантического анализатора у нас будет среда разработки не хуже, чем jdt.

> нельзя напрямую использовать библиотеки, написанные на C++

А кто может? Страуструп похоже специально написал язык так, чтобы с ним было максимально сложно работать компиляторам.

> Есть опасность, что язык черезмерно усложнят

Согласен. К счастью, это пока не наступило, и, если та презентация - окончательный проект, не наступит.

> Думаю Java или .NET залезут во все щели раньше, что люди созреют использовать D

Так же можно сказать, что винда и макось залезет во все щели раньше, чем люди созреют использовать Линукс. Общая проблема всех проектов, на которых не строится прибыль какой-нибудь большой компании.

> D хуже отсутствием платформы.

В новостных группах это иногда упоминают. Уолтер Брайт всегда убедительно доказывает, что платформа для всех, казалось бы, специфичных для платформенных языков фичей, вовсе не обязательна:

http://www.digitalmars.com/d/archives/digitalmars/D/D_vs_VM-based_platforms_5...

и

http://www.digitalmars.com/d/archives/digitalmars/D/Re_D_vs._C_60648.html#N60648

Библиотека Tango содержит все то, что мне когда-либо было нужно. Платформозависимый код аккуратно отделен от кроссплатформенного. Кроме того, всегда можно вызвать функции из сишных библиотек. И почти каждая, уважающая себя библиотека на C++ имеет биндинги для C.

Кстати, в Tango есть vfs, а в jdk - нет.

> Ну и чего, perl вообще $%_@#$!_@#$## нечитаем, и живет себе.

Перл подыхает (см. TPCI)

> D хуже отсутствием платформы.

Наоборот. Он не будет тащить за собой монструозный фреймворк, как это делают жабо и шарп.

> Кстати, в Tango есть vfs, а в jdk - нет.

Вот, умный человек по D нашёлся! Давно хотел спросить - чем танга лучше фобоса? Стоит ли на неё ориентироваться? Совместима ли она с 2.0?

> Вот, умный человек по D нашёлся!

Спасибо. :) Умных людей по D на самом деле много, но по-русски из них говорит человек 5. =D

> Давно хотел спросить - чем танга лучше фобоса? Стоит ли на неё ориентироваться? Совместима ли она с 2.0?

По функциональности: Фобос - практически подмножество Танго. Танго гораздо больше и мощнее. В Танго чаще используются классы, имеется обьектно-ориентированный ввод-вывод, traced exceptions (надо просто подлинковать к твоей программе flectioned), поправлено несколько багов в GC и потоках. И это далеко не все. К недостаткам можно отнести разве что желание косить под "платформы" (много лишнего и слишком специализированного), глубокую иерархию модулей (кому-то не нравится печатать tango.util.collection.LinkSeq ради простого списка) и несовместимость с Фобос.

Насчет совместимости: В 1.0 Танго совместима с Фобос через Tangobos. С последней версии танго их разработчики (Tango - The Tango Team и Tangobos - Gregor Richards) скоординировались и теперь будут выпускать соответствующие друг другу версии в один день. Я проверил. И не на HelloWorld, а на большой программке, линкующейся к двум либам. Одна либа на Фобосе, вторая - на Танго. Может я что-то не так делал, но мне напильник понадобился. Правда в итоге заработало ВСЕ. Если нужны инструкции по установке, скажи как-нибудь.

В 2.0 пишут объединенный runtime от Tango и Phobos. т.е. практически единственная несовместимость между танго и фобос исчезнет. Но эта работа еще не закончена.

Вывод: если используешь D2 - только фобос, если же D1 - то tango+tangobos

В любом случае настоятельно рекомендую dsss: http://www.dsource.org/projects/dsss

Мне не удалось заставить tangobos работать "ручной" установкой. Наверно руки кривые. Зато установленное через dsss все работает идеально.

Кстати можешь посоветовать учебник по D? А то получается, что юзаю язык только в рамках возможностей С. Офиц. доки с digitalmars читаются тяжело. :( Или может какой исходник есть, где все фичи ЯП юзаются на практике?

> учебник по D

Если с английским языком и $$$ проблем нет, то http://dblog.aldacron.net/2007/12/05/a-book-about-d-and-tango/

Почти все фичи на практике показаны в статьях на http://digitalmars.com/d/comparison.html И они читаются легче, чем доки. Для полного познания The D Way в метапрограммировании могу посоветовать только медитирование над кодом Don'а Clugston'а =D например библиотечку meta или blade на http://www.dsource.org

А вообще, лучше бы ты переходил с Джавы, а не с С. А еще лучше - с обоих. Тогда бы почти все само собой понятно было.

> Перл подыхает (см. TPCI)

(Visual) Basic впереди C++ !!! Страуструп должен застрелиться, я считаю.

А с тем, что питон более правилен, чем перл, я всегда был согласен.

Будем следить за D. Может и правда С++ - это и правда аналог автомобиля с паровым двигателем. Был такой период в автостроении, когда паромобили казались более перспективными (им даже принадлежали рекорды скорости), но развитие ДВС быстро сделало их неперспективными...

> (Visual) Basic впереди C++ !!!

TPCI - не лучший показатель качества языка. Одно время D был выше Delphi, т.к. вышла версия 1.0 и почти сразу произошло разделение. Вся блогосфера это обсуждала. Посмотри на график любого языка и станет ясно, что tpci доверять нельзя.

http://www.ohloh.net/languages можно было бы считать более правильной статистикой, но сейчас он включает только open-source проекты и то далеко не все.

> Но на это никто не среагировал.

Кажется, я могу пояснить, почему ваш крик души остался незамеченным.

Во-первых, язык Шекспира и Роулинг в вашем исполнении, прямо скажем, не блестящ. Даже меня, вашего соотечественника, фразы типа "If those methods are const than compiler (or run-time) could made their invocation in parallel" заставляют почесать затылок.

Во-вторых, ваши претензии не особо осмысленны. В первом случае, кто мешает вам написать:

state = cast(ChannelState)channels[client_name];

И вообще, скажем прямо, возвращать результат в параметрах есть моветон. Избегайте. В вашем случае функция должна возвращать state, а в отсутствии канала в ассоцмассиве - кидать эксепшн.

Во втором случае вы просто хотите невозможного. Представьте, что у вас есть два message, которые ссылаются на один notifier. И они обрабатываются одновременно, в двух потоках. И два потока одновременно будут пытаться изменить один notifer. Что происходит? А пёс его знает. Вся транзакционная изоляция летит этому же псу под хвост.

Нет уж. Если дядя Уолтер сказал "всё должно быть иммутабельным", значит надо слушать дядю Уолтера. Он хорошо над этим подумал.

По поводу descent. Вы надеюсь шутите про возможности аналогичные jdt. Возмжноны два вариант 1) вы не пользовались jdt 2)вы считаете что команада jdt *** гоняет, раз она столько времени делелала jdt для языка _гораздо_ проще чем D. У меня есть подозрения что в некоторой степени верны оба варианта. =)

> По поводу descent. Вы надеюсь шутите про возможности аналогичные jdt. Возмжноны два вариант 1) вы не пользовались jdt

А ты сам-то пользовался SVN-версией Descent? ;)

> По поводу descent. Вы надеюсь шутите про возможности аналогичные jdt.

Последний раз я использовал jdt около года назад. Потом перешел на NetBeans. Возможно за этот год что-то было добавлено в jdt.

Но у разработчиков Descent было преимущество в виде открытых исходников jdt и примера для подражания.

> А ты сам-то пользовался SVN-версией Descent? ;)

На самом деле она глючновата... т.е. болше 5 минут в час не работает. :D

>> Но на это никто не среагировал.

> Кажется, я могу пояснить, почему ваш крик души остался незамеченным.

Ну хоть кто-то откликнулся. Даже если его и не просили. И даже если ничего путного не сказал. Все равно спасибо.

> Во-первых, язык Шекспира и Роулинг в вашем исполнении, прямо скажем, не блестящ. Даже меня, вашего соотечественника, фразы типа "If those methods are const than compiler (or run-time) could made their invocation in parallel" заставляют почесать затылок.

Грешно смеятся над убогими. Английский мне не родной и даже в школе не довелось его изучать. И живу там, где носителей языка днем с огнем не найдешь. И попросить проверить мой английский кого-либо возможности не было. Так что "Don't shot the pianist..."

> Во-вторых, ваши претензии не особо осмысленны. В первом случае, кто мешает вам написать:

> state = cast(ChannelState)channels[client_name];

Ахринительно! Вводим const для того, чтобы снимать его с помощью каста. За что боролись, на то и напоролись.

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

И кстати, не знаете, почему в C++ ввели специальную конструкцию, const_cast? Чтобы принудительное снятие константности было видно невооруженным взглядом и легко выискивалось простым grep-ом. А в D обычный cast, который применяется направо и налево, делает такие опасные вещи.

> И вообще, скажем прямо, возвращать результат в параметрах есть моветон. Избегайте. В вашем случае функция должна возвращать state, а в отсутствии канала в ассоцмассиве - кидать эксепшн.

Если бы я хотел бросать исключение -- я бы бросал. Но это такой метод, который вызывается слишком часто и во многих местах. И оборачивать каждый его вызов в try/catch -- верный способ засрать исходник и просадить производительность.

Возвращать что-нибудь -- это хороший вариант. Но данный код был калькой с C++, где нет ни туплов, ни анонимных типов, ни чего-либо подобного. Поэтому возврат нескольких значений (а мне таки нужно было два, не смотря на очепятки и описки в примере) через out-параметры -- вполне подходящий и дешовый способ.

> Во втором случае вы просто хотите невозможного. Представьте, что у вас есть два message, которые ссылаются на один notifier. И они обрабатываются одновременно, в двух потоках. И два потока одновременно будут пытаться изменить один notifer. Что происходит? А пёс его знает. Вся транзакционная изоляция летит этому же псу под хвост.

Ерунду говорите, дорогой товарищь. Защита notifier от параллельной модификации -- проблема самого notifier. Его метод addSubscriber вполне может быть synchonized. Либо он может ничего не изменять, а отсылать кому-нибудь новое сообщение, т.е. способен работать на нескольких контекстах сразу. Защищать от одновременной модификации нужно не notifier, а message. И с этим const справляется (хотя кто запретит применить к нему cast? Вы вот парой абзацев выше лихо константность с помощью каста сняли). Но вот когда из константности message следует константность notifier -- это уже диверсия.

> Нет уж. Если дядя Уолтер сказал "всё должно быть иммутабельным", значит надо слушать дядю Уолтера. Он хорошо над этим подумал.

Настолько хорошо, что реализация const/invariant меняется уже в N-ный раз. И, вероятно, не в последний.

А не подскажите, куда это делся final для переменных? Над ним же дядя Уолтер так же хорошо подумал. А как на счет того, что шаблоны в D вообще не планировались? Ведь это же была ключевая фича D по сравнению с C++.

Так что слухи по поводу того, что дядя Уолтер о чем-то хорошо подумал, на практике оказываются сильно преувеличенными.

> Так что слухи по поводу того, что дядя Уолтер о чем-то хорошо подумал, на практике оказываются сильно преувеличенными.

Просто с первого раза не всегда получается хорошо подумать. ;)

Все таки константность - в D2. Подумать еще раз и изменить всегда можно. А то, что Уолтер никого не подпускает к дизайну языка - правда:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gro...

> Настолько хорошо, что реализация const/invariant меняется уже в N-ный раз. И, вероятно, не в последний.

Потому что "no issue left behind" и ни один императивный язык программирования не сделал ее правильно. Поэтому и меняется с каждым вторым релизом... Как говорится until we get it right. С С++ можно было слизать работающие фичи, обходя стороной или изменяя неработающие. Константность слизывать не с чего, а Ошибок было допущено недостаточно много, чтобы сделать из них однозначные выводы.

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

>> Так что слухи по поводу того, что дядя Уолтер о чем-то хорошо подумал, на практике оказываются сильно преувеличенными.

> Просто с первого раза не всегда получается хорошо подумать. ;)

Вот и я о том же.

> Все таки константность - в D2.

Тогда нужно рассматривать D2 как совсем другой язык. Так и говорить, что D и D2 -- это два разных языка. И пусть D развивается сам по себе. А D2 -- сам по себе.

А то сейчас ситуация какая-то невероятная: можно начинать что-то делать на D1, постоянно помня, что пройдет какое-то время и придется переписывать изрядную часть кода после выхода D2. Нигде еще такого не видел. Даже в Python и Ruby решились на создание несовместимых версий языка после N лет обеспечения совместимости.

> А то, что Уолтер никого не подпускает к дизайну языка - правда:

> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gro.. .

И это правильно, в принципе. Единоначалие лучше чем ситуация с C++ коммитетом.

>> Настолько хорошо, что реализация const/invariant меняется уже в N-ный раз. И, вероятно, не в последний.

> Потому что "no issue left behind" и ни один императивный язык программирования не сделал ее правильно. Поэтому и меняется с каждым вторым релизом... Как говорится until we get it right. С С++ можно было слизать работающие фичи, обходя стороной или изменяя неработающие. Константность слизывать не с чего, а Ошибок было допущено недостаточно много, чтобы сделать из них однозначные выводы.

Когда в D заговорили про константность, я так же думал, что C++ный вариант если не плох, то не очень хорош. И что можно сделать лучше. Но затем подумал, посмотрел на творящийся в D 2.0 маразм понял, что в C++ уже нашли лучше, что можно было сделать в императивном языке. Более строгие гарантии разве что в ФП. В C++ константность не дураки добавляли, и не от хорошей жизни там и константность не транзитивная, да еще и mutable добавили.

Как бы Вальтер в конце-концов к тому же не пришел.

> Как бы Вальтер в конце-концов к тому же не пришел.

К тому же не придет, но какой будет константность в конце концов, сказать сложно. Скорее всего не все будет так плохо. Есть десятки развивающихся проектов. Если кому-то придется слишком часто использовать грязные хаки, например, описанные yk4ever, будет ясно, что что-то не так. И будет исправлено. Я сам не использую D2, поэтому не могу сказать достоверно, чем текущий режим константности плох. А рассуждать сейчас не время. ИМХО в случае с D2 проблему не нужно решать раньше, чем с ней кто-нибудь столкнется на практике. Тогда будет ясно чем именно вызвана проблема и как лучше ее решить.

> Ахринительно! Вводим const для того, чтобы снимать его с помощью каста. За что боролись, на то и напоролись.

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

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

> А в D обычный cast, который применяется направо и налево, делает такие опасные вещи.

Между прочем, Уолтер открытым текстом говорил: "каст, сцуко, опасный, постарайтесь им не пользоваться".

> Если бы я хотел бросать исключение -- я бы бросал. Но это такой метод, который вызывается слишком часто и во многих местах. И оборачивать каждый его вызов в try/catch -- верный способ засрать исходник и просадить производительность.

Как бы буллщет. Проверка на эксепшн практически эквивалентна if по влиянию на производительность. Реально кинуть его - да, стоит дорого, но это и должно случаться нечасто. Вообще, я на вашем месте бы сначала позаботился о корректности и поддерживаемости программы, а не о скорости. Что там дедужка Кнут про предварительную оптимизацию вещал?

> Но данный код был калькой с C++, где нет ни туплов, ни анонимных типов, ни чего-либо подобного. Поэтому возврат нескольких значений через out-параметры -- вполне подходящий и дешовый способ.

Не надо калькировать с С++. Если уж взялись за D, должны понимать, что C++ - FUBAR. От "дешовых" способов лучше отказаться. И, тем более, в C++ есть struct, его никто не отменял.

> Но вот когда из константности message следует константность notifier -- это уже диверсия.

Это не диверсия, а правила игры. Нотифайер является частью мессаджа. Вы пообещали не менять мессадж (и такми образом сняли вопрос транзакционной защиты) - вы не можете менять его часть. Либо вы работаете в константах (и все спокойны), либо вы вручную занимаетесь проблемами многопоточности. На двух стульях не усидишь.

> ИМХО в случае с D2 проблему не нужно решать раньше, чем с ней кто-нибудь столкнется на практике. Тогда будет ясно чем именно вызвана проблема и как лучше ее решить.

Что значит на практике? Я вот на практике не могу даже D1 применить, поскольку релиза Tango еще даже нет. А делать серьезный проект на постоянных бета-версиях -- это не серьезно. Такими темпами D2 на практике вообще непонятно когда можно будет попробовать.

А по поводу константности -- я прикинул, как собственные C++ разработки перевести на D2. Не получилось, транзитивная константность не позволяет. Это считается практикой или нет?

> Уолтер открытым текстом говорил: "каст, сцуко, опасный, постарайтесь им не пользоваться".

Для этого и ключевое слово добавил. Чтобы grep'ать плохой код с cast'ами.

>> Но вот когда из константности message следует константность notifier -- это уже диверсия.

>Это не диверсия, а правила игры. Нотифайер является частью мессаджа

Я кое-что не могу понять. В каждом message ровно один notifier? И каждей notifier - ровно у одного message? Если так, что почему бы их не обьединить? Если один notifier может быть у нескольких message, тогда eao197 прав и notifier не является частью message.

> Я вот на практике не могу даже D1 применить, поскольку релиза Tango еще даже нет. А делать серьезный проект на постоянных бета-версиях -- это не серьезно. Такими темпами D2 на практике вообще непонятно когда можно будет попробовать.

Мне не приходилось ничего менять ни с одним релизом Танго. Единственное исключение - последний релиз:

:%s/toUtf8/toString/g

по всем файлам. И все скомпилилось и заработало.

Путь от Mango+Ares до Tango 0.99.4 был пройден всего за год.

Набрел на интересную статью: http://www.dsource.org/projects/tango/wiki/DeActive Кто-то пытается на основе Tango реализовать Active Record.

> А по поводу константности -- я прикинул, как собственные C++ разработки перевести на D2. Не получилось, транзитивная константность не позволяет. Это считается практикой или нет?

Нет. D2 еще находится в стадии разработки.

А за счет своей навороченной константности они пытаются достичь выгрыша в параллелизме. ИМХО.

> А за счет своей навороченной константности они пытаются достичь выгрыша в параллелизме. ИМХО.

1. Вид контракта.

2. Самодокументируемый код

3. Оптимизация ( и параллелизм )

4. Функциональное программирование.

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

>> А по поводу константности -- я прикинул, как собственные C++ разработки перевести на D2. Не получилось, транзитивная константность не позволяет. Это считается практикой или нет?

> Нет. D2 еще находится в стадии разработки.

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

Это можно считать практикой, но нужно помнить, что это - _только_ для feedback'а Уолтеру. Все равно все еще будет меняться.

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

> Это можно считать практикой, но нужно помнить, что это - _только_ для feedback'а Уолтеру.

Это нельзя считать практикой - результат практики идет в реальную эксплуатацию; Feedback Вальтеру - это участие в разработке языка. Тоже практическая деятельность, но другого плана :)

> Я же говорю, out-параметры - это вообще неправильная штука. Функция должна явно возвращать свои результаты. Между прочем, Уолтер открытым текстом говорил: "каст, сцуко, опасный, постарайтесь им не пользоваться". Как бы буллщет. Проверка на эксепшн практически эквивалентна if по влиянию на производительность. Вообще, я на вашем месте бы сначала позаботился о корректности и поддерживаемости программы, а не о скорости. Не надо калькировать с С++. Если уж взялись за D, должны понимать, что C++ - FUBAR.

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

>> Но вот когда из константности message следует константность notifier -- это уже диверсия.

> Это не диверсия, а правила игры. Нотифайер является частью мессаджа. Вы пообещали не менять мессадж (и такми образом сняли вопрос транзакционной защиты) - вы не можете менять его часть.

Не угадали. notifier не является частью сообщения. Часть сообщения является _ссылка_ на notifier и именно ее должен защищать const. Нельзя поменять ссылку на notifier внутри объекта message, поскольку этот message может обрабатываться в этот же самый момент любым другим потоком. Но вот внутренности notifier к содержимому message не имееют отношения.

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

А вы задумывались, что const для данных не обеспечивает _никаких_ гарантий в многопоточности и не дает _никаких_ преимуществ для оптимизатора (в отличии от invariant)? Наличие const ссылки обеспечивает всего лишь _read only view_. Но кто-нибудь другой может изменить этот же самый объект в другом потоке имея не const ссылку. Поэтому когда вам, как потребителю объекта message, дают const message, то это вам запрещают его менять. Но никто не гарантирует вам, что объект не измениться в то время, пока вы с ним работаете. Поэтому const никак не спасает от проблем многопоточности.

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

Речь идёт о том, что у вас проблема загнать const-значение в out-параметр. Я думаю, тут основная проблема не в const, а именно в out.

> Но вот внутренности notifier к содержимому message не имееют отношения.

Почему же не имеют? Если нотифайер является элементом иммутабельного мессаджа, то вполне логично, что нотифайеру тоже следует быть иммутабельным.

> А вы задумывались, что const для данных не обеспечивает _никаких_ гарантий в многопоточности и не дает _никаких_ преимуществ для оптимизатора (в отличии от invariant)?

:] Вы противоречите себе же. В посте в digitalmars.D вы же сами заявляли, что делаете данные константными именно для-ради многопоточности. А тут говорите, что даже от транзитивной константности проку нет! Что уж тогда говорить про нетранзитивную?

На самом деле const конечно обеспечивает кое-какие гарантии при определённых условиях. Компилятор/рантайм теоретически в состоянии проконтролировать отсутствие мутабельных ссылок на данные в определённый момент времени

Другое дело, что сейчас он этого явно не делает. Так что если константность вам мешает - можете от неё отказаться в принципе.

> На самом деле const конечно обеспечивает кое-какие гарантии при определённых условиях. Компилятор/рантайм теоретически в состоянии проконтролировать отсутствие мутабельных ссылок на данные в определённый момент времени

const параметр гарантирует, что функция не будет его менять. invariant гарантирует, что эти данные никогда не изменятся. Не понимаю, как может const помочь многопоточности или оптимизатору? Он существует только как документация и контракт. Вот invariant может многое гарантировать и без контроля со стороны компилятора/рантайма.

Учитыавя всю экспериментальность D2 было бы неплохо перевести все обсуждение на английский - и на рассмотрение коллегам. На ЛОР от него будет не много толку.

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

> Речь идёт о том, что у вас проблема загнать const-значение в out-параметр. Я думаю, тут основная проблема не в const, а именно в out.

Проблема не в этом, пора бы уже понять. Проблема в том, что из-за константности this следует константность _всех ссылок_ в this.channels. Хотя константность следовало бы распространить только на сам объект this.channels, но не на ссылки, которые в нем находятся.

>> Но вот внутренности notifier к содержимому message не имееют отношения.

>Почему же не имеют? Если нотифайер является элементом иммутабельного мессаджа, то вполне логично, что нотифайеру тоже следует быть иммутабельным.

Да поймите: notifier _не является частью_ сообщения! Просто не является. Notifier создается кем-то еще до создания сообщения. И сообщение нужно только для того, чтобы передать notifier заинтересованным сторонам. Более того, время жизни message вполне может быть меньше времени жизни notifier.

Naryl еще одно правильное предположение сделал: для одного объекта notifier в системе может существовать несколько объектов message.

>> А вы задумывались, что const для данных не обеспечивает _никаких_ гарантий в многопоточности и не дает _никаких_ преимуществ для оптимизатора (в отличии от invariant)?

> :] Вы противоречите себе же. В посте в digitalmars.D вы же сами заявляли, что делаете данные константными именно для-ради многопоточности.

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

На тот момент, когда я отсылал пост в digitalmars.D я думал, что в принципе, компилятор или run-time _могли бы_ запускать подобные методы (если бы их было несколько) в параллель, поскольку подобные методы не модифицируют this. Но потом понял, что вряд ли компилятор когда-либо сможет сделать это вообще.

> А тут говорите, что даже от транзитивной константности проку нет!

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

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

> Что уж тогда говорить про нетранзитивную?

А в C++ она есть и нормально работает.

> На самом деле const конечно обеспечивает кое-какие гарантии при определённых условиях.

Какие гарантии и в каких условиях?

> Так что если константность вам мешает - можете от неё отказаться в принципе.

Тогда зачем ее было делать??? И представте себе, как передача сообщений в многопоточной программе выполняется без константных ссылок. Один экземпляр message передается в несколько нитей одновременно. Ничто не защищает message от того, чтобы кто-то по ошибке или недосмотру, не занулил в нем поле notifier. И если такая ошибка возникает, то искать ее придется очень и очень долго. А нетранзитивная константность устраняет данный класс ошибок полностью.

> const параметр гарантирует, что функция не будет его менять. invariant гарантирует, что эти данные никогда не изменятся. Не понимаю, как может const помочь многопоточности или оптимизатору? Он существует только как документация и контракт. Вот invariant может многое гарантировать и без контроля со стороны компилятора/рантайма.

+1

Более того, мне кажется, что в D2 сейчас не хвает специального оператора для конструирования инвариантных объектов. Т.е. для строки или вектора инвариантную копию можно получить посредством свойства idup. Но вот как сконструировать инвариантный объект пользовательского типа?

Мне кажется, что наличие специальной формы оператора new здесь было бы к месту:

auto message = new(invariant) Message( notifier );

или

auto message = new invariant(Message)( notifier );

Тем самым гарантируется, что message никогда и никем не может быть изменен. Получается настоящее ФП.

PS. DMD 2.009 позволяет писать new invariant(Message), но созданный объект инвариантом не является, его можно изменять.

Я спросил про твою (или языка) проблему на digitalmars.D.learn.

Пол дня прошло, никто не пока ответил.

> auto message = new(invariant) Message( notifier );

Этот синтаксис сейчас работает и называется использованием custom allocator'а. т.е. вызвает allocator класса Message с параметром invariant. Скорее всего будет ошибка identifier expected, 'invariant' found.

> auto message = new invariant(Message)( notifier );

Этот вариант мне нравится больше. Но еще лучше было бы

auto message = new invariant Message( notifier );

или

auto message = inew Message( notifier );

Но это все лишнее, т.к. когда в D2 будут polysemous values, new сможет возвращать одновременно и invariant и не invariant. Компилятор присвоит в message ту версию, которая нужна. т.е. сработает и

invariant message = new Message( notifier );

и

auto message = new Message( notifier );

В первом случае message будет инвариантна, а во втором нет.

В D2 еще реализованы не все фичи, призванные обеспечить комфортную работу с константностью.

> Проблема в том, что из-за константности this следует константность _всех ссылок_ в this.channels.

Это ж тривиальный случай транзитивности. Так значит вам не по душе транзитивная константность в принципе! Ну тогда и надо было говорить прямо: "я против в принципе", а не "в некоторых случаях мешает, можно бы опционально..."

> Да поймите: notifier _не является частью_ сообщения!

Да поймите: это зависит от точки зрения! Я лично считаю, что расценивать его как часть сообщения - вполне логично. Вот смотрите, писали вы статью о мировой экономике, и привели в ней ссылку на исследование динамики объёмов производства резиновых утят в бразилии. А потом хозяин сайта, где были резиновые утятя, забыл проплатить хостинг. И хоба! если кто-то будет читать вашу статью и пойдёт по ссылке, он данных не найдёт. Там теперь дефолтная страница хостера. Как результат, ваша статья может быть непонятой. Целостность нарушена.

> А в C++ она есть и нормально работает.

В этом ваша беда - вы принимаете D за "C++ с улучшениями". А тут надо осознавать, что Уолтер намеренно пытается построить философию, в корне отличную от философии C++. И поэтому портировать код 1:1 не получится. Его надо продумывать заново.

> Какие гарантии и в каких условиях?

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

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

Как ёжики размножаются - очень, очень осторожно :] Хотя, при желании, никто не мешает вам выстроить систему передачи сообщений на константной транзитивности. Только надо думать немного по-другому.

>> Да поймите: notifier _не является частью_ сообщения!

>Да поймите: это зависит от точки зрения! Я лично считаю, что расценивать его как часть сообщения - вполне логично.

И все-таки ассоциация и агрегация - разные вещи. При агрегации транзитивная константность логична и правильна. При ассоциации - нет. Здесь мы имеем ассоциацию.

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

Буду очень рад увидеть пример. Сам ради этой штуки вчера скачал D2. Пока ничего не получилось...

> Пока ничего не получилось...

Получилось. И транзитивность константности не помешала. Проблема на самом деле была в public поле, а не в out параметре и т.п.

http://paste.dprogramming.com/dpxp2bhk

Как видим, изменить ссылку на notifier в message нам не дадут, а вот получить notifier и копаться в нем - пожалуйста. Скажите, если я неправильно понял задачу.

> Проблема на самом деле была в public поле,

Да если честно - и не в нём. С public тоже всё, оказалось, работает. Ха! Подозреваю, камрад "Yauheni" нас ввёл в заблуждение - или он использовал D2 более ранней версии.

> а не в out параметре и т.п.

Out-параметр - это был в другом примере.

> Получилось. И транзитивность константности не помешала. Проблема на самом деле была в public поле, а не в out параметре и т.п.

> http://paste.dprogramming.com/dpxp2bhk

> Как видим, изменить ссылку на notifier в message нам не дадут, а вот получить notifier и копаться в нем - пожалуйста. Скажите, если я неправильно понял задачу.

Но заметь, чтобы отдать нам notifier приходится явно снимать константность с помощью cast-а в методе getter-е. Это ничем не лучше того, что предлагал y4ever. И мои возражения по поводу использования cast-ов ему остаются актуальными и в этом случае.

И еще -- пришлось делать два метода getter-а: один константный, второй не константный. Это лишняя писанина.

>> Проблема в том, что из-за константности this следует константность _всех ссылок_ в this.channels.

> Это ж тривиальный случай транзитивности. Так значит вам не по душе транзитивная константность в принципе! Ну тогда и надо было говорить прямо: "я против в принципе", а не "в некоторых случаях мешает, можно бы опционально..."

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

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

> Вот смотрите, писали вы статью о мировой экономике, и привели в ней ссылку на исследование динамики объёмов производства резиновых утят в бразилии. А потом хозяин сайта, где были резиновые утятя, забыл проплатить хостинг. И хоба! если кто-то будет читать вашу статью и пойдёт по ссылке, он данных не найдёт. Там теперь дефолтная страница хостера. Как результат, ваша статья может быть непонятой. Целостность нарушена.

Доказательство по аналогии -- это демагогия. Кроме того, было несколько попыток создать что-то типа WWW. И мы имеем тот WWW, который есть сейчас (как раз допускающий битые ссылки) именно потому, что в нем не было попытки обеспечить глобальную целостность. Остальные модели пытались ее обеспечить и просто не выжили.

>> Какие гарантии и в каких условиях?

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

Ну и как это упрощает разработку многопоточных программ?

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

> Как ёжики размножаются - очень, очень осторожно :] Хотя, при желании, никто не мешает вам выстроить систему передачи сообщений на константной транзитивности. Только надо думать немного по-другому.

Ануткать. Продемонстрируйте идейку.

> И еще -- пришлось делать два метода getter-а: один константный, второй не константный. Это лишняя писанина.

Упс. Здесь зарапортавался. Getter был один, второй был setter.

> Но заметь, чтобы отдать нам notifier приходится явно снимать константность с помощью cast-а в методе getter-е. Это ничем не лучше того, что предлагал y4ever. И мои возражения по поводу использования cast-ов ему остаются актуальными и в этом случае.

Да. В данном случае без транзитивности исчез бы cast, но семантически ничего бы не изменилось. Ссылку по-прежнему нельзя было бы присваивать, а менять notifier можно было бы. Фактичеки, этот getter - просто способ снять транзитивную константность. В связи с этим предлагаю попробовать и посмотреть, будет ли транзитивность нужна чаще, чем не нужна? Если один вариант не будет иметь четкого преимущества над другим, то нужен и транзитивный и нетранзитивный const.

> Да. В данном случае без транзитивности исчез бы cast, но семантически ничего бы не изменилось. Ссылку по-прежнему нельзя было бы присваивать, а менять notifier можно было бы. Фактичеки, этот getter - просто способ снять транзитивную константность.

Так вот мне и не нравится то, что снятие константности с помощью cast становится таким образом _легальным_ приемом программирования на D. Получается, что C++ ругали за const_cast и за наличие mutable, за то что это обеспечивает "логическую константность", в то время как D стремиться обеспечить "физическую константность". Но в итоге в D получается то же самое.

Кроме того, сейчас снятие константности и последующая модификация объекта в D ведет к undefined behaviour. Т.е подобный getter не является корректной конструкцией.

PS. Кстати, проблемы с new invariant(Message)() оказались багом компилятора. Что радует :)

> Кроме того, сейчас снятие константности и последующая модификация объекта в D ведет к undefined behaviour. Т.е подобный getter не является корректной конструкцией.

notifier - не invariant. Через message он const, а снимать const - не undefined behavior. Снимать invariant - undefined behavior.

> PS. Кстати, проблемы с new invariant(Message)() оказались багом компилятора. Что радует :)

Порадовал баг? :)

> notifier - не invariant. Через message он const, а снимать const - не undefined behavior. Снимать invariant - undefined behavior

http://www.digitalmars.com/d/const3.html -- там табличка в конце и сказано, что modification after casting away const -- undefined behavior.

> Порадовал баг? :)

Порадовался, что это всего лишь баг.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.lea...

По-моему хорошая идея. Делаем все поля invariant и read-only property для notifier. Или message - не всегда invariant?

> Так может переориентироваться на GTK и добавить в Glade поддержку D?

Поддержка Glade уже ксть в gtkD

http://www.dsource.org/projects/gtkd