public class Transform
{   
   public float M11, M12, M13, 
                M21, M22, M23, 
                M31, M32, M33, 
                M41, M42, M43; 
}

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

public class Transform
{   
   public mutable M11, M12, M13, 
                  M21, M22, M23, 
                  M31, M32, M33, 
                  M41, M42, M43:float; 
}

Это не подходит языку или есть другие причины?

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

R>Это не подходит языку или есть другие причины?

Думаю что причины две.
Во-первых, это не Паскаль.
Во-вторых, это никому не нужно.

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

VD>Во-вторых, это никому не нужно.

Жаль, я частенько использую в шарпе.

Тогда ещё вопрос вдогонку.
На этот раз по поводу интеграции, перевожу большие куски из шарпа в NemerleStudio и при количестве ошибок эдак больше 400 при редактировании кода начинает частенько подвисать. Так лучше не делать? Это нормальное поведение или только у меня такое? Количество ошибок так сильно снижает скорость построения AST?

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

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

VD>>Во-вторых, это никому не нужно.

R>Жаль, я частенько использую в шарпе.

И зря. Это ухудшает читаемость. Даже в соглашениях по форматированию кода от МС оговоривается описание по одному члену типа на строке.

R>На этот раз по поводу интеграции, перевожу большие куски из шарпа в NemerleStudio и при количестве ошибок эдак больше 400 при редактировании кода начинает частенько подвисать. Так лучше не делать? Это нормальное поведение или только у меня такое? Количество ошибок так сильно снижает скорость построения AST?

Дело не в АСТ, а именно в списке ошибок. Он в VS (при большом объеме) начинает тормозить.

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

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

VD>И зря. Это ухудшает читаемость. Даже в соглашениях по форматированию кода от МС оговоривается описание по одному члену типа на строке.

Да, возможно, просто в некоторых случаях это удобно. var ведь тоже может ухудшать.

VD>Дело не в АСТ, а именно в списке ошибок. Он в VS (при большом объеме) начинает тормозить.
Хех, забавно. Кстати да, в шарпе, насколько я понимаю, стоит ограничение на список выдаваемых ошибок, не больше 500, вроде.

VD>Если речь идет о том, что исходник копипэстится и потом подправляется, то можно просто в начале файла поставить открывающий коментаний "/*", а когда код будет приведен в соответствие (ошибок останется не много) убрать этот коментарий.

Угу, так и делаю. Спасибо.

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

R>Да, возможно, просто в некоторых случаях это удобно. var ведь тоже может ухудшать.

"var" это вроде как совсем не про поля и совсем не про Nemerle .

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

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

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

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

R>Кстати да, в шарпе, насколько я понимаю, стоит ограничение на список выдаваемых ошибок, не больше 500, вроде.

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

Когда проект в нормальном состоянии — это очень удобно. Ведь изменение в одном исходнике может вызвать ошибки в другом. За счет вывода всех ошибок мы это сразу же видим. Но платой за это являются тормоза при большом количестве ошибок. Особенно неприятно кода такие ошибки появляются в следствии того, что не доступна некоторая библиотека (т.е. в самих исходниках ошибки нет).

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

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

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

R>>Да, возможно, просто в некоторых случаях это удобно. var ведь тоже может ухудшать.

VD>"var" это вроде как совсем не про поля и совсем не про Nemerle .

Ну да, но понятно, что я имел в виду.


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

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

Да, теперь избавился от лага чуть по-другому. Просто отжал кнопку Errors в ErrorList'e и никаких задержек, всё летает и супер удобно. Интересно новая версия студии имеет те же проблемы. По идее в WPF есть VirtualizingStackPanel.

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

R>Да, теперь избавился от лага чуть по-другому.

Кстати, тоже хороший выход из положения. Я как-то даже не задумывался над таким вариантом.

R>Просто отжал кнопку Errors в ErrorList'e и никаких задержек, всё летает и супер удобно. Интересно новая версия студии имеет те же проблемы. По идее в WPF есть VirtualizingStackPanel.

Надо смотреть.

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

R>Да, теперь избавился от лага чуть по-другому. Просто отжал кнопку Errors в ErrorList'e и никаких задержек, всё летает и супер удобно.

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

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

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

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


А я вот еще тупо не нашел как шарпдевелопу подсунуть сообщения об ошибках и потому вижу их только при компиляции.

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

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

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