Ребят, вот только сейчас задался вопросом, а какие объектные (и не очень) свойства поддерживает Немерля? А то всё макросы, макросы, а главного-то и не знаем!
Есть ли множ. наследование? Всякие полиморфизмы, статики, дженерики, контракты, friends, mixins, ну и т.п.
По всему этому есть какой-то документ?

И ещё вопрос: реально ли в Немерле поддержать свою модель? Скажем, вот захочу я прилепить множ.наследование, я смогу в немерлёвые объекты занести свойства других объектов?

Здравствуйте, matumba, Вы писали:

M>Есть ли множ. наследование? Всякие полиморфизмы, статики, дженерики, контракты, friends, mixins, ну и т.п.
M>По всему этому есть какой-то документ?

То же что и в C# (кроме ансейф) + варианты + кортежи + лямбды + алиасы типов.

Здравствуйте, matumba, Вы писали:

M>И ещё вопрос: реально ли в Немерле поддержать свою модель? Скажем, вот захочу я прилепить множ.наследование, я смогу в немерлёвые объекты занести свойства других объектов?

Нет. В Nemerle 2.0 можно будет вводить конструкции верхнего уровня (заместо class или struct).
Сейчас можно заменять полиморфизм наследования на полиморфизм включения — пробросить методы и свойства тривиально несложным макросом.

Здравствуйте, hardcase, Вы писали:

H>То же что и в C# (кроме ансейф)

Не совсем всё, что в C#. Есть ограничения в реализации generic интерфейсов.
Кроме того, AFAIK, не поддерживаются vararg методы (хотя и в C# эта фича недокументирована).

Здравствуйте, nikov, Вы писали:

N>Не совсем всё, что в C#. Есть ограничения в реализации generic интерфейсов.

Это какие?

N>Кроме того, AFAIK, не поддерживаются vararg методы (хотя и в C# эта фича недокументирована).

Ну, значит ее таки нет?
Вообще, твой педантизм часто переходит границы разумного. Тот же vararg не только недокументированная фиыча, но к тому же еще и не применяемая пользователями на практике. Единственно где я ее видел — это в исходниках Ротора.

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

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, hardcase, Вы писали:

H>>То же что и в C# (кроме ансейф)

N>Не совсем всё, что в C#. Есть ограничения в реализации generic интерфейсов.
N>Кроме того, AFAIK, не поддерживаются vararg методы (хотя и в C# эта фича недокументирована).

vararg — элемент объектной модели (что бы ни значило это словосочетание)?

Здравствуйте, VladD2, Вы писали:

N>>Не совсем всё, что в C#. Есть ограничения в реализации generic интерфейсов.
VD>Это какие?

interface IConvertible[T] { }

class A : IConvertible[int], IConvertible[string] { }

A.n:3:1:3:54: ←[01;31merror←[0m: type `IConvertible.[T]' is implemented by type `A' twice under different instantiations
A.n:3:1:3:54: ←[01;31merror←[0m: second one directly
A.n:3:1:3:54: ←[01;31merror←[0m: types string and int are not compatible

N>>Кроме того, AFAIK, не поддерживаются vararg методы (хотя и в C# эта фича недокументирована).

VD>Ну, значит ее таки нет?
Как будто бы в Nemerle все фичи документированы.

VD>Вообще, твой педантизм часто переходит границы разумного.
Работа такая.

Здравствуйте, hardcase, Вы писали:

M>>И ещё вопрос: реально ли в Немерле поддержать свою модель? Скажем, вот захочу я прилепить множ.наследование, я смогу в немерлёвые объекты занести свойства других объектов?

H>Нет...

Ну, почему же нет? Занести свойства других объектов несомненно можно. На этом основаны макросы Design patterns. Другое дело, что реализация именно множественного наследования входит в конфликт с дотнетом в котором оно не поддерживается. Можно, конечно, пойти путем Эфиля, но при этом будут нарушены компонентные принципы, что на мой взгляд намного хуже чем отсутствие множественного наследования. Но что-то вроде миксинов создать можно. Вот только хотят это только те, что только-только перешел с плюсов. Я вот уже давно не испытываю потребности в МН. Даже указанные паттерны применяю очень редко. Хотя 10 лет назад очень часто пользовался МН.

Здравствуйте, nikov, Вы писали:

N>

N>interface IConvertible[T] { }

N>class A : IConvertible[int], IConvertible[string] { }
N>

N>

N>A.n:3:1:3:54: ←[01;31merror←[0m: type `IConvertible.[T]' is implemented by type `A' twice under different instantiations
N>A.n:3:1:3:54: ←[01;31merror←[0m: second one directly
N>A.n:3:1:3:54: ←[01;31merror←[0m: types string and int are not compatible
N>

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

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

Вопрос только нужно ли это хоть кому-то? За все время кроме тебя на это вроде бы никто не замечал. Значит оно на практике никому не нужно. А делать работу ради галочки не хочется. Так что можно счесть это несущественным недостатком и забить на него.

Здравствуйте, nikov, Вы писали:

VD>>Ну, значит ее таки нет?
N>Как будто бы в Nemerle все фичи документированы.

А это то тут причем? Да и речь вообще-то была о ОО-модели. Какое отношение недокументированная фича в области передачи параметров влияет на несоответствие ОО-моделей?

Вот с реализацией интерфейсов — согласен. Но это скорее косяк в компиляторе. По ума надо его конечно устранить. Попробую на досуге. А то может его поправить проще чем объяснять, что оно на фиг не нужно .

VD>>Вообще, твой педантизм часто переходит границы разумного.
N>Работа такая.

Тут все же обратная зависимость. Работка такая, потому...

Здравствуйте, VladD2, Вы писали:

N>>interface IConvertible[T] { }

N>>class A : IConvertible[int], IConvertible[string] { }

VD>Вопрос только нужно ли это хоть кому-то? За все время кроме тебя на это вроде бы никто не замечал. Значит оно на практике никому не нужно. А делать работу ради галочки не хочется. Так что можно счесть это несущественным недостатком и забить на него.

Если никто не замечал этот баг в Немерле, это не означает, что никто этим не пользуется

Здравствуйте, _FRED_, Вы писали:

VD>>Вопрос только нужно ли это хоть кому-то? За все время кроме тебя на это вроде бы никто не замечал. Значит оно на практике никому не нужно. А делать работу ради галочки не хочется. Так что можно счесть это несущественным недостатком и забить на него.

_FR>Если никто не замечал этот баг в Немерле, это не означает, что никто этим не пользуется

Да замечали конечно (и в багтреке запись есть) — это косяк дизайна, который вот так за один вечер точно не исправить.

Здравствуйте, hardcase, Вы писали:

VD>>>Вопрос только нужно ли это хоть кому-то? За все время кроме тебя на это вроде бы никто не замечал. Значит оно на практике никому не нужно. А делать работу ради галочки не хочется. Так что можно счесть это несущественным недостатком и забить на него.

_FR>>Если никто не замечал этот баг в Немерле, это не означает, что никто этим не пользуется

H>Да замечали конечно (и в багтреке запись есть) — это косяк дизайна, который вот так за один вечер точно не исправить.

То, что не исправить, это понятно. Но, реально, весьма и весьма нужно.

Здравствуйте, _FRED_, Вы писали:

_FR>

N>>>interface IConvertible[T] { }

N>>>class A : IConvertible[int], IConvertible[string] { }
_FR>

_FR>Если никто не замечал этот баг в Немерле, это не означает, что никто этим не пользуется

Это скорее означает, что если этим кто-то и пользуется, то все равно это не является насущной необходимостью.

Здравствуйте, VladD2, Вы писали:

N>>>>interface IConvertible[T] { }

N>>>>class A : IConvertible[int], IConvertible[string] { }

_FR>>Если никто не замечал этот баг в Немерле, это не означает, что никто этим не пользуется
VD>Это скорее означает, что если этим кто-то и пользуется, то все равно это не является насущной необходимостью.

Ну откуда же у вас полномочия решать, что есть "насущность"?

Для Немерле это действительно может быть и не важно (может, есть и более серьёзные ошибки/недоработки в компиляторе), но это не может быть "не насущным" для релизной версии какого-то бы нибыло компилятора (языка, позволяющего реализувывать интерфейсы) под дотнет. Это я как пользователь компиляторов заявляю :о))

Эх, был бы R# рабочий, я среди исходников бы и нашёл примеры классов, реализующих один и тот же генерик-интерфейс. Буден настроение, попробую в качестве изучения с вашим шарповым парсером написать xpath-искалку по исходникам. Очень мне уж понравилась эта идея.

Здравствуйте, _FRED_, Вы писали:

_FR>Ну откуда же у вас полномочия решать, что есть "насущность"?

У кого у вас? Решают пользователи. Если баг сообщил Ников и за два года никто его не подтвердил (не сообщил об аналогичном баге), это означает, что хотя проблема формально и существуют, но на практике никому не мешает.

Даже в МС так живут. Всех багов не исправишь. Приходится сосредотачиваться на том, что важнее. Если баг элементарный и может быть легко устранен за час, то его тоже устранят. Но когда баг системные (люди просто реализовали ограниченную логику) и при это он никому кроме человека педантично проверявшего соответствие стандарту шарпа не помешало за несколько лет, то приоритет у такого бага очень низкий.

_FR>Для Немерле это действительно может быть и не важно (может, есть и более серьёзные ошибки/недоработки в компиляторе), но это не может быть "не насущным" для релизной версии какого-то бы нибыло компилятора (языка, позволяющего реализувывать интерфейсы) под дотнет. Это я как пользователь компиляторов заявляю :о))

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

_FR>Эх, был бы R# рабочий, я среди исходников бы и нашёл примеры классов, реализующих один и тот же генерик-интерфейс. Буден настроение, попробую в качестве изучения с вашим шарповым парсером написать xpath-искалку по исходникам. Очень мне уж понравилась эта идея.

Зачем xpath? Лучше уж тогда прямо использовать квази-цитаты. Или смесь xpath и квази-цитат. Что-то типа:

..$modifiers MyMethod(..$parms) $body

где modifiers, parms и body сопоставляются с модификаторами доступа, параметрами и телом метода (соответственно) и их можно использовать для каких-то целей.

Здравствуйте, VladD2, Вы писали:

_FR>>Ну откуда же у вас полномочия решать, что есть "насущность"?

VD>У кого у вас? Решают пользователи. Если баг сообщил Ников и за два года никто его не подтвердил (не сообщил об аналогичном баге), это означает, что хотя проблема формально и существуют, но на практике никому не мешает.

Но это ни разу не говорит о том, на сколько данная функциональность используется вообще в дотнетном коде.

VD>Даже в МС так живут. Всех багов не исправишь. Приходится сосредотачиваться на том, что важнее. Если баг элементарный и может быть легко устранен за час, то его тоже устранят. Но когда баг системные (люди просто реализовали ограниченную логику) и при это он никому кроме человека педантично проверявшего соответствие стандарту шарпа не помешало за несколько лет, то приоритет у такого бага очень низкий.

Мне кажется это очень странный взгляд на разработку. И вижу я его, к сожелению, не впервой: до тех пор, пока C#-програмисты не увидят, что код на Немерле можно писать как минимум так же, как и на шарпе, _начинать_ писать на Немерле не будет никто (кроме очень заинтересованных людей, но ведь не это же конечная цель проекта)? Но, конечно, не мне учить, как и куда развивать проект, может ваша стратегия и окажется более лучшей.

_FR>>Для Немерле это действительно может быть и не важно (может, есть и более серьёзные ошибки/недоработки в компиляторе), но это не может быть "не насущным" для релизной версии какого-то бы нибыло компилятора (языка, позволяющего реализувывать интерфейсы) под дотнет. Это я как пользователь компиляторов заявляю :о))

VD>Языку вообще по фигу. Он не живой. Важно или не важно для юзеров. Если за баг голосуют хотя бы двое, то он автоматически становится более приоритетным. Так же баг становится более приоритетным, если пользователь сообщает, что баг блокирует работу.

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

При расстановке приоритетов надо понимать, что важна не только частота, с которой баг может встречаться в пользовательском коде, но маркетинговый некий приоритет: то, что работает всё, имеющееся в шарпе (или есть некий архитектурный/принципиальный момент, почему нечно не работает или работает по-другому). А если подобные ошибки считаются низкоприоритетными, то использовать такую технологию не интересно, как бы не хотелось.

_FR>>Эх, был бы R# рабочий, я среди исходников бы и нашёл примеры классов, реализующих один и тот же генерик-интерфейс. Буден настроение, попробую в качестве изучения с вашим шарповым парсером написать xpath-искалку по исходникам. Очень мне уж понравилась эта идея.

VD>Зачем xpath? Лучше уж тогда прямо использовать квази-цитаты. Или смесь xpath и квази-цитат. Что-то типа:

VD>..$modifiers MyMethod(..$parms) $body

VD>где modifiers, parms и body сопоставляются с модификаторами доступа, параметрами и телом метода (соответственно) и их можно использовать для каких-то целей.

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

Здравствуйте, _FRED_, Вы писали:

_FR>Да мне очень нужна утилита, которая просто позволит по указанной строке находить нужные ветки в коде, для использования в качестве фронтэнда, а не для написания программ.

В принципе такая хотелка вполне реализуема. Где-то за вечер-другой — движок уже есть.

Здравствуйте, _FRED_, Вы писали:

_FR>Но это ни разу не говорит о том, на сколько данная функциональность используется вообще в дотнетном коде.
+100

Вот я использую это в C# коде. Соответственно, у меня будут проблемы если я буду переводить код на Nemerle. Но нельзя сварить яичницу не разбив ни одной сковородки. Хотя у меня на этом завязано много что в редакторе.

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

Если Влад говорит, что есть сложность в реализации, то выбора нет. В конце-концов у Немерля и так нет достойных аналогов на .net. И то, что уже сделано, это огромное достижение.

Но жалко!

Здравствуйте, _FRED_, Вы писали:

_FR>Но это ни разу не говорит о том, на сколько данная функциональность используется вообще в дотнетном коде.

От чего же? Если фича не востребована, то она не востребована.

VD>>Даже в МС так живут. Всех багов не исправишь. Приходится сосредотачиваться на том, что важнее. Если баг элементарный и может быть легко устранен за час, то его тоже устранят. Но когда баг системные (люди просто реализовали ограниченную логику) и при это он никому кроме человека педантично проверявшего соответствие стандарту шарпа не помешало за несколько лет, то приоритет у такого бага очень низкий.

_FR>Мне кажется это очень странный взгляд на разработку.

Это совершенно нормальный подход. Еще раз повторюсь, что МС поступает точно так же. Ты же не выставляешь претензии к МС по поводу того, что их компилятор не всегда соответствует спецификации, а куча их продуктов имеют незакрытые баги? Вот если бы тебе не удалось скомпилировать обычный код, тогда — да, ты бы сильно возмущался.

_FR>И вижу я его, к сожелению, не впервой: до тех пор, пока C#-програмисты не увидят, что код на Немерле можно писать как минимум так же, как и на шарпе, _начинать_ писать на Немерле не будет никто

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

_FR>(кроме очень заинтересованных людей, но ведь не это же конечная цель проекта)?

Я тебе открою секрет. Нет каких "очень заинтересованных людей" есть три класса дотент-программистов которым может быть интересен немерл:
1. Те кто его толком не пробовал, но занимаются обсуждением.
2. Те кто его пробовал и использует.
3. Те кто его пробовал, но использовать не может, так как начальство не дает.

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

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

Еще раз, стратегия очень простая. Если фича востребованная (или баг достаждающий), то она реализуется/исправляется в первую очередь. Определяется — это двумя критериями 1) количеством людей обнаруживших баг/недоделку, 2) критичностью ошибки/фичи. В данном случае мы имеем мало востребованную фичу которая легко обходится на практике, т.е. мало-нужная и не критичная.

Однако вокруг этой мало-нужной фигни были развернуты крутые дебаты (с подачи Воронкова, за что ему отдельное спасибо).

На сегодня я вынужден из-за этого тратить время на эту мало-полезную фигню и не заниматься более важными вещами. Я было занялся причесыванием и ускорением вывода типов для вложенных лямбд (что, например, должно ускорить вывод типов для LINQ), но теперь я вынужден переключиться и заниматься черти чем что еще лет 10 никому на практике не пригодится.

Результат — релиз откладываются, флэйм прогрессирует.

Внимание, вопрос. А кому от этого польза?

_FR>В данном случае нужно отталкиваться от других критериев: я на немерле не програмирую и до тех пор, пока в нём есть вот такие вот баги, даже не начну ничего важного делать.

Ты ищешь причины чтобы что-то не делать. Я и так уверен, что ты их найдешь. Спроси всех кто программирует на немерле — "мешало ли, на практике, отсутствие этой фичи хоть кому-то?". Уверен, что ответ будет отрицательным.

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

Блин, с какими ошибками? Кто вообще обещал 100%-ное соответствие? В немерле много чего реализовано иначе нежели в C#. И в VB, например, тоже. Но кто-то уперся в иное поведение и пытается навязать мнение, что — это фатальный недостаток, хотя совершенно очевидно, что проблема на практике не стоит и выеденного яйца.

_FR>При расстановке приоритетов надо понимать, что важна не только частота, с которой баг может встречаться в пользовательском коде, но маркетинговый некий приоритет: то, что работает всё, имеющееся в шарпе (или есть некий архитектурный/принципиальный момент, почему нечно не работает или работает по-другому). А если подобные ошибки считаются низкоприоритетными, то использовать такую технологию не интересно, как бы не хотелось.

Сори, я устал объяснять одно и то же.

Отвечу послединй раз. Nemerle не C#. Всем кто хочет иметь клон C# и кого устраивает его убогость нужно просто продолжать писать на C#, так как Nemerle никогда не станет полным его клоном. Nemerle не для тех кто упирается в несущественные мелочи, а для тех кто хочет сделать свою работу более эффективной и более интересной.

Более того, если ты (или кто-то другой) хочешь найти что-то что позволит тебе сказать "Вот видите, как же при этом использовать Nemerle?", то просто не надо этого делать. Можно и так не использовать Nemerle, без всяких собственных оправданий.

Использование языка — это не героический поступок и или дань моде. Это решение которое принимает программист (или его начальник). И оно должно быть обосновано (если принимающие его субъекты не идиоты) взвешиванием за и против.

Скажем кроме совершенно не существенных расхождений с шаропом по реализации интерфейса у немерла есть намного большие различия. Например, в Немреле нет unsafe. Это уже существенное различие. И если оно важно, то конечно Nemerle не для вас.

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

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

_FR>Да мне очень нужна утилита, которая просто позволит по указанной строке находить нужные ветки в коде, для использования в качестве фронтэнда, а не для написания программ.

Нужна — сделай. Для этого все есть.