DMD 2.015 & DMD 1.031

> именно поэтому я и спросил какое он право имеет называться D, к примеру С++ обратно совместим с С - т.е. является его продолжением

Уже подал в суд на МС за C#?

При виде auto myVar = myFunc(); сходу тип не определить, но это считается плохим стилем

auto i = arr.iterator;

Нафига мне здесь писать тип i? Я часто использую auto, никаких проблем на замечал.

> Что это за язык, на который стандарта нету и который мутирует от месяца к месяцу

4.2, он уже года полтора не изменяется. Не путать со второй альфа-версией.

> бывает очень неудобно, когда он действительно нужен

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

>Я часто использую auto, никаких проблем на замечал.

В каком языке?

"Легко" это настолько эфемерное понятие.
Ведь и без парашюта тоже легко до земли долетищь. Просто приземление будет неудобное.

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

Интерфейсы это параплан, а утиная типизация - телепорт, в то время пока остальные летят на парашуте в загон свиней.

> стречал быдл, которые на макросах писали все, даже классы.

glib?

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

Какие проблемы могут быть с множественным наследованием? Просто такие холивары вокруг этого мне кажутся странными. Делать одновременно интерфейс и абстрактный класс его реализующий, со скелетной имплементацией части методов, как в Яве - это слишком многословно 2 my mind.

> Какие проблемы могут быть с множественным наследованием?

Не знаю, мне самому не понятно. Я за множественное наследование, но его отсутствие для меня не является существенным минусом.

В D, вроде про него говорим. И в языках, имеющих аналогичные конструкции. И в С++ буду использовать, если появится. Особенно мне "нравится" код вроде

for (std::vector<std::list<std::string> >::const_iterator i = v.begin(); i != v.end(); ++i) { ... }

только typedef-ами и спасаюсь.

>В D, вроде про него говорим.

У тебя есть проект на D?

> Большая часть идей для последней версии принадлежит Андрею Александреску

Этот язык умирает, толком даже ещё и не родившись.

Да. Две курсовые работы и будущая дипломная.

> Да. Две курсовые работы и будущая дипломная.

Ну и кому это в реальном мире нахер надо? Очередной студент-вебобыдлокодер? Сынок, покажи нормальный бизнес план хотя бы.

Кстати, о чём речь-то шла? о_О

Наследование - зло.
Множественное наследование - абсолютное зло. В нормальных языках есть либо интерфейсы, либо mixin'ы - закаченные стероидами интерфейсы.

Ты лучше расскажи что с ромбами делать будешь в проекте.

>> Большая часть идей для последней версии принадлежит Андрею Александреску

>Этот язык умирает, толком даже ещё и не родившись.

Этот матерый человечище написал на С++ обобщенный указатель на функцию полностью на стандартном С++ без единого хака. И даже потрудился объект-трамплин разместить в спецкуче для мелких объектов.

> Наследование - зло.

Absurd, перелогинься.

>Absurd, перелогинься.

tailgunner, у тебя паранойя =)

>> Наследование - зло.

>Absurd, перелогинься.

Я никогда ничего не говорил против наследования. ЧЗБ?

> у тебя паранойя =)

Нет, это _они_ - ВЕЗДЕ!

> Я никогда ничего не говорил против наследования.

Стиль высказывания похож. Ну и аргументация тоже %)

Ну-ну расскажи-ка дружочек что бывает если у тебя дерево эдак в 15 наследований образовалось, и ВНЕЗАПНО нужно поменять в самом его корне скажем тип возвращаемого значения одной из функций.

Наследование строго не рекомендуется использовать везде где это возможно. Выходи из леса, почитай да просвятись маленько http://209.85.135.104/search?q=cache:n3H8wk5Ina8J:www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp...

Нет просто некоторые любят одним корявым молотком все проблемы решать. И пельмени варить и детей расчесывать.

Будет глядеть, будем. Вот выйдет версия 2, вот подтянется gdc, и поглядим :)

>кстати насчет "препроцессор - зло", у него много применений -

добавь сюда ещё "возможность сделать время компиляции модулей" квадратичным

> Ну-ну расскажи-ка дружочек что бывает если у тебя дерево эдак в 15 наследований образовалось, и ВНЕЗАПНО нужно поменять в самом его корне скажем тип возвращаемого значения одной из функций.

Ичо? Расскажи-ка мне, дружочек, что бывает, если у тебя дерево вызовов этак в 15 уровней, и ВНЕЗАПНО нужно поменять в самом самом нижнем уровне скажем тип возвращаемого значения одной из функций.

> Наследование строго не рекомендуется использовать везде где это возможно

Я в курсе. Меня аргументы не убеждают - всё в стиле "мы наворотили кучу хлама, и она развалилась, когда мы пытались выдернуть какую-то фигню из ее основания".

Не городите куч хлама (== "не делайте слишком глубоких иерархий").

С такими аргументами нужно было на ассемблере хакать, а лучше сразу в машинных кодах. А фигли! Не надо куч наварачивать, у меня все работает, сразу думать надо было итд итп.

> С такими аргументами нужно было на ассемблере хакать

Я пишу и на ассемблере тоже.

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

Вот видишь, ты и сам всё знаешь. Кстати, так что делать с глубоким деревом вызовов функций? Не использовать функции?

>я верно понимаю, что программу на с/с++ компилятором D скомпилировать нельзя?

зависит от программы. Были примеры quin-программ на 3 языках сразу, C, Perl, фортран, что-то ещё. Один исходник успешно компилировался несколькими компиляторами :))

не, языки-то разные, портировать код надо. А всякие фичи С++ или там сигналы/слоты для moc портировать функционально аналогичным кодом на D.

>обратите свое внимание на Ada и Eiffel. На нем хоть серьезные проекты есть

а какие есть серьёзные проекты на Эйфеле? а то вдруг интересно стало. Желательно с DBC и юниттестами понатыканными.

>Меня аргументы не убеждают - всё в стиле "мы наворотили кучу хлама, и она развалилась, когда мы пытались выдернуть какую-то фигню из ее основания".

У тебя все доводы сводится к предварительному 100%-ному проектированию. А программы растут поступательно. Прикажешь закладывать изначально Visitor в каждую иерархию, чтобы расширять функционал извне по мере поступления/изменения требований?

>> Меня аргументы не убеждают - всё в стиле "мы наворотили кучу хлама, и она развалилась, когда мы пытались выдернуть какую-то фигню из ее основания".

> У тебя все доводы сводится к предварительному 100%-ному проектированию.

Ничего подобного. То, что они наворотили кучу хлама - это не упрек (хорошая память не позволяет бросаться камнями 8) ). Упрек в том, что они винят не себя/обстоятельства/МЗЧ, а наследование. Ну и вопрос, на который не ответил Анонимус I - представь себе глубоко вложенные вызовы функций, и тебе нужно поменять тип где-то в глубине. Чем это лучше случая с глубоким наследованием, можешь внятно объяснить?

> Прикажешь закладывать изначально Visitor в каждую иерархию, чтобы расширять функционал извне по мере поступления/изменения требований?

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

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

"Правильно" писать можно только то, что развитию не подлежит в принципе. То есть написал четко по ТЗ, продал и досвидания. Пишем с нуля новое.

>Ну и вопрос, на который не ответил Анонимус I - представь себе глубоко вложенные вызовы функций, и тебе нужно поменять тип где-то в глубине. Чем это лучше случая с глубоким наследованием, можешь внятно объяснить?

А ничем не лучше, разве я агитировал за использование кучи вложенных функций? Кстати что делать с ромбами? И главный вопрос - зачем нужен инструмент, у коротого куча условностей и скрытых ловушек стремиться к + бесконечности?

>"Правильно" писать можно только то, что развитию не подлежит в принципе. То есть написал четко по ТЗ, продал и досвидания. Пишем с нуля новое.

Открой для себя Agile - технологии

> А ничем не лучше, разве я агитировал за использование кучи вложенных функций?

Не агитировал. Но ты агитировал за отказ от наследования - почему же не за отказ от использования функций?

> Кстати что делать с ромбами?

Стараться их избегать. Не удалось - разбираться по месту возникновения проблемы.

> И главный вопрос - зачем нужен инструмент, у коротого куча условностей и скрытых ловушек стремиться к + бесконечности?

Ммм... это о каком инструменте сказано? О D? o_O Ну а условности и скрытые ловушки есть везде, я щитаю.

Я вообще-то специально не ограничился ими при написании поста. Не аджайлом единым как говориться. Главное просто учитывать, что функция требований по времени не является константой.

>Упрек в том, что они винят не себя/обстоятельства/МЗЧ, а наследование

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

>Ну и вопрос, на который не ответил Анонимус I - представь себе глубоко вложенные вызовы функций, и тебе нужно поменять тип где-то в глубине.

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

>Ну и вообще такие вещи решаются грамотной организацией процесса разработки, работой с заказчиком и прочими нетехническими мерами.

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

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

правильно - долой проектирование, да здравствует прибивание гвоздями сбоку новой функциональности ;)

Блин, давно мечтаю об _удобном_ языке с возможностью написания для него оптимизирующего компилятора. Мож D оправдает мои надежды? Я сам особо в нем не разбирался но очень жду от _нового_ языка _новых_ фич, как то:

- встроенная поддержка списков - встроенная поддержка регулярных выражений - лямбда-выражения и функции высших порядков - возможность расширения классов и объектов (пусть даже не динамическая, как в руби или питоне, а как в C# 3.0) - систему метапрограммирования, например как в Nemerle - компактность языка

Так че там есть и чего нету?

>правильно - долой проектирование, да здравствует прибивание гвоздями сбоку новой функциональности ;)

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

> и вопрос, на который не ответил Анонимус I - представь себе глубоко вложенные вызовы функций, и тебе нужно поменять тип где-то в глубине. Чем это лучше случая с глубоким наследованием, можешь внятно объяснить?

my take (хотя мы и не Анонимус I): "глубоко вложенные вызовы функций" -- это глубоко вложенные определения функций, то есть, замыкания. Тогда при смене типа в глубине и если тип этой свободной переменной явно нигде не используется, стоит auto, менять ничего не придётся, ибо замыкание.

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

Вы бы с веществами завязывали.

> если у тебя дерево эдак в 15 наследований образовалось, и ВНЕЗАПНО нужно поменять в самом его корне скажем тип возвращаемого значения одной из функций

сколько??? это ж каким извращенцем надо быть :) а поможет обычный рефакторинг с помощью IDE

Перекрёстное наследование. Когда у 2х родителей уже усть общие прародители, бывает сложно определить откуда взята реализация базовго класса.

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

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

Долой класс ориентированное ООП! Рассадник лишних сущностей... Пора давно уже переходить на прототипно-ориентированное.