пытаюсь из экземпляра читать статическое поле, получаю
trying to access static member (field: static delta : int through an instance
с каких пор это стало ошибкой?
в сравнениях не поддерживается короткая запись?
if (x) ..
when (!obj) ..
это почемуйто? вроде не сложно определить value оно или нет и сравнить с 0 или null..
в struct объявленные поля не public по умолчанию, но вообще-то на то он и struct, что у него все public.
или здесь особый struct?
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, _Claus_, Вы писали:
__>>>// Указание генерика __>>>def s : List.[int] = f.load.[int](2); __>>>def s = f.load.[int](2); __>>>def s : List.[int] = f.load(2); __>>>[/nemerle]
_C_>>спасибо, помогло!
__>А чем плох вариант: "def s = f.load(2)" ? __>Писать меньше и типы автоматически выводятся.
У меня тип шаблона не совпадает с типом параметра.
Здравствуйте, _Claus_, Вы писали:
_C_>Есть вопросы, проясните, плз
Я так понимаю вы из среды С++.
Язык Nemerle старается придерживаться правил С# и здравого смысла.
Поэтому поведение некоторых вещей отличается от С++.
_C_>пытаюсь из экземпляра читать статическое поле, получаю _C_>trying to access static member (field: static delta : int through an instance _C_>с каких пор это стало ошибкой?
В C# это является ошибкой, и в Nemerle тоже.
Статические методы нужно вызывать напрямую через тип.
_C_>в сравнениях не поддерживается короткая запись? _C_>if (x) .. _C_>when (!obj) .. _C_>это почемуйто? вроде не сложно определить value оно или нет и сравнить с 0 или null..
Что означает запись
if (x)
if (x != null) или if (x != 0) ?
В С# так нельзя и в Nemerle тоже.
Вообще, ничего сложно в написании "!= null" , "!= 0" совершенно нет.
А если использовать Pattern Matching то вообще практически не нужно.
_C_>в struct объявленные поля не public по умолчанию, но вообще-то на то он и struct, что у него все public. _C_>или здесь особый struct?
Все как в C#, public нужно всегда объявлять.
Кстати struct в .Net это не struct в С++ понимании
_C_>в макросе с аттрибутом
_C_>
На мой взгляд это недочет, но режим с отступами не является основным режимом языка на сегодня.
Поэтому есть недочеты, но их всегда можно устранить если есть время и желания
_C_> def s = f.load[int](2) //вариант 1
_C_> def s : List[int] = f.load(2) //вариант 2
_C_>
_C_>оба не помогают _C_>некоторые методы, например load в datamap принимают шаблон struct, который в параметрах метода не обозначен. _C_>компилятор обзывается: _C_>cannot find any suitable indexer in 'List' (type is ? -> ?) _C_>и еще всякое по мелочи..
С первым вариантом все ясно. Тут неоднозначность между индексером и параметром типов. Нужно просто подставить точку:
def s = f.load.[int](2)
А вот второй вариант должен работать.
Какую версию ты используешь? В 1.1 бэта такой код должен компилироваться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_C_>> def s = f.load[int](2) //вариант 1
_C_>> def s : List[int] = f.load(2) //вариант 2
_C_>>
VD>А вот второй вариант должен работать. VD>Какую версию ты используешь? В 1.1 бэта такой код должен компилироваться.
Сори, заметил проблему только после второго прочтения. Просто не нежно задавать параметры типов явно. В Немерле очень мощный вывод типов. Он разруливает типы в 99% случаев. Так что указывать параметры типов явно нужно очень редко.
Более того, вывод типов возможен из использования. Так что если за строчкой:
def s = f.load(2);
будет идти что-то вроде:
s.Add(42);
то компилятор все равно корректно выведет тип.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
_C_>У меня тип шаблона не совпадает с типом параметра.
Ну, а дальше эту переменную s как используешь? Почти уверен, что немерловый компилятор без труда выведет типы из дальнешего использования. Попробуй выбросить параметры типов полностью и поглядеть что будет.
И вообще, привыкай больше доверять выводу типов. По сравнению с Boo или F# в немерле, он намного совершеннее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
_C_>в сравнениях не поддерживается короткая запись? _C_>if (x) .. _C_>when (!obj) .. _C_>это почемуйто? вроде не сложно определить value оно или нет и сравнить с 0 или null..
Потому что это потенциальный багодром. Это ведь не просто сокращения в when или if — это неявные приведения между bool и числами. В некоторых комбинациях это приводит к трудно уловимым ошибкам. Например, мотерые С++-ники обычно пишут проверки раком: "null == x", только для того чтобы не нарваться на случайные гралши.
По тем же причинам "=" не возвращает значения и их нельзя связать в последовательность: "a = b = c;".
_C_>в struct объявленные поля не public по умолчанию, но вообще-то на то он и struct, что у него все public. _C_>или здесь особый struct?
Есть только один тип в котором по умолчанию поля public — это вхождение вариантов. Во всех стальных местах по умолчанию все члены являются private. Это соглашение всех без исключения C-подобных языков.
_C_>в макросе с аттрибутом
_C_>
Очень советую поглядеть исходники стандартной библиотеки макросов. И вообще, код компилятора и библиотек дает 99% ответов связанных с написанием макросов. Лично я учил немерл, в основном, на его основе. Например, вот код макроса написанный в индент-стиле.
В прочем, если можешь себя перебороть, то лучше перейти на скобочный стиль, так как только он поддерживается в IDE. Иначе с комплитом и другими сервисами IDE будут проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _nn_, Вы писали:
__>Я так понимаю вы из среды С++.
Скорее из Питона. Он же говорил, что Boo использует. В Питоне много спорных решений было сделано. Одно объявление переменных первым присвоением чего стоит.
_C_>>пытаюсь из экземпляра читать статическое поле, получаю _C_>>trying to access static member (field: static delta : int through an instance _C_>>с каких пор это стало ошибкой?
__>В C# это является ошибкой, и в Nemerle тоже. __>Статические методы нужно вызывать напрямую через тип.
Не совсем так. Из экземплярного метода можно обращаться к статическому без квалификации имени. Ну, что-то типа:
private static Foo() : void {}
public Bar() : void
{
Foo(); // OK
}
Происходит это потому, что внутри типа его тип является текущим.
А вот доступ через this действительно запрещен:
Это очевидная ошибка о которой нужно сообщать программисту. Ведь, скорее всего, он не ошибается думая, что Foo экземплярный метод. Вместо this тут может быть свойство или поле.
Короче, человек привык к багодромному языку и теперь строгость малость напрягает. Тут ничего не поделаешь, придется немного привыкнуть. Зато потом куча ошибок просто не сможет появиться, а значит будет меньше отладки.
__>Вообще, ничего сложно в написании "!= null" , "!= 0" совершенно нет. __>А если использовать Pattern Matching то вообще практически не нужно.
Скажу больше. Есть операторы .? и ??. Если их грамотно использовать, то код станет в разы короче, безопаснее и понятнее.
А еще лучше не допускать появления null используя макро-атрибут для параметров [NotNull]. Ну, а для выражения отсутствия значения использовать option[T] или ValueOption[T].
Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности.
__>Все как в C#, public нужно всегда объявлять.
Во вхождениях вариантов поля по умолчанию public.
__>На мой взгляд это недочет, но режим с отступами не является основным режимом языка на сегодня. __>Поэтому есть недочеты, но их всегда можно устранить если есть время и желания
Ну, дык соберите команду тех кого интересует этот режим и устраните этот недочет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _nn_, Вы писали:
__>>Я так понимаю вы из среды С++.
VD>Скорее из Питона. Он же говорил, что Boo использует. В Питоне много спорных решений было сделано. Одно объявление переменных первым присвоением чего стоит.
В Питоне нет автоматического приведения типов в целое для if. Это из С/C++.
VD>Не совсем так. Из экземплярного метода можно обращаться к статическому без квалификации имени. Ну, что-то типа: VD>Это очевидная ошибка о которой нужно сообщать программисту. Ведь, скорее всего, он не ошибается думая, что Foo экземплярный метод. Вместо this тут может быть свойство или поле.
+1
VD>Короче, человек привык к багодромному языку и теперь строгость малость напрягает. Тут ничего не поделаешь, придется немного привыкнуть. Зато потом куча ошибок просто не сможет появиться, а значит будет меньше отладки.
__>>Вообще, ничего сложно в написании "!= null" , "!= 0" совершенно нет. __>>А если использовать Pattern Matching то вообще практически не нужно.
VD>Скажу больше. Есть операторы .? и ??. Если их грамотно использовать, то код станет в разы короче, безопаснее и понятнее. VD>А еще лучше не допускать появления null используя макро-атрибут для параметров [NotNull]. Ну, а для выражения отсутствия значения использовать option[T] или ValueOption[T].
А NotNull нельзя приделать к методу ? Чтобы одним махом все проверять на null:
[NotNull] public F(a : int, b : string, c : object, d : long) : void { ... }
Превращается в ==>
public F(a : int, [NotNull] b : string, [NotNull] c : object, d : long) : void { ... }
VD>Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности.
А этот VariantOption когда стоит использовать вместо option ?
Только для производительности ? Ведь для юзер кода option должно хватить.
__>>На мой взгляд это недочет, но режим с отступами не является основным режимом языка на сегодня. __>>Поэтому есть недочеты, но их всегда можно устранить если есть время и желания
VD>Ну, дык соберите команду тех кого интересует этот режим и устраните этот недочет.
Можно попробовать, только боюсь ни у кого на это нет времени
Да и для меня скобочки не смертельный вариант.
В С-подобных языках вообще выбора нет
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _Claus_, Вы писали:
_C_>>в сравнениях не поддерживается короткая запись? _C_>>if (x) .. _C_>>when (!obj) .. _C_>>это почемуйто? вроде не сложно определить value оно или нет и сравнить с 0 или null..
VD>Потому что это потенциальный багодром.
Слишком вы тут осторожные, однако. Не хватает воображения, чтобы это давало какие-то проблемы.
У меня так точно не было, несмотря на многие годы интенсивного использования.
а вот вместо сравнения написать присваивание — это сколько угодно.
Так что не согласен я с Каутским.
VD>По тем же причинам "=" не возвращает значения и их нельзя связать в последовательность: "a = b = c;".
_C_>>в struct объявленные поля не public по умолчанию, но вообще-то на то он и struct, что у него все public. _C_>>или здесь особый struct?
VD>Есть только один тип в котором по умолчанию поля public — это вхождение вариантов. Во всех стальных местах по умолчанию все члены являются private. Это соглашение всех без исключения C-подобных языков.
в С++ открытые. значит в С# стали чудить, но я на нем не пишу. но это потому что в Майкрософте народу много, чтобы всех занять придумывают раздутый синтаксис, из пальца высосанные ограничения и низкий уровень языков.
VD>Очень советую поглядеть исходники стандартной библиотеки макросов. И вообще, код компилятора и библиотек дает 99% ответов связанных с написанием макросов. Лично я учил немерл, в основном, на его основе. Например, вот код макроса написанный в индент-стиле.
Смотрю регулярно, хорошо написано, но понятно не все.
VD>В прочем, если можешь себя перебороть, то лучше перейти на скобочный стиль, так как только он поддерживается в IDE. Иначе с комплитом и другими сервисами IDE будут проблемы.
что-нибудь милое и знакомое оставить надо. для психики лучше. и для кода тоже.
еще вот не понял как простые стандартные фиксированные массивы создаются (которые в шарпе типа System.Int32[])
есть ли короткая запись для такого типа?
__>В C# это является ошибкой, и в Nemerle тоже. __>Статические методы нужно вызывать напрямую через тип.
Может я наивен, но смысла в этом никакого, а вред вполне ощутимый.
нафига использующей стороне знать детали реализации моего класса?
Я могу изменить экземплярное на статическое или наоборот — вызывающий код зачем переделывать?
потому что в Майкрософте им виднее ..
Здравствуйте, _Claus_, Вы писали:
_C_>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, _Claus_, Вы писали:
_C_>>>в сравнениях не поддерживается короткая запись? _C_>>>if (x) .. _C_>>>when (!obj) .. _C_>>>это почемуйто? вроде не сложно определить value оно или нет и сравнить с 0 или null..
VD>>Потому что это потенциальный багодром.
_C_>Слишком вы тут осторожные, однако. Не хватает воображения, чтобы это давало какие-то проблемы. _C_>У меня так точно не было, несмотря на многие годы интенсивного использования.
А зачем тогда в С++ придумали Safe-Bool Idiom, explicit operator cast ? Не от хорошей жизни наверное
_C_>а вот вместо сравнения написать присваивание — это сколько угодно. _C_>Так что не согласен я с Каутским.
VD>>По тем же причинам "=" не возвращает значения и их нельзя связать в последовательность: "a = b = c;".
_C_>>>в struct объявленные поля не public по умолчанию, но вообще-то на то он и struct, что у него все public. _C_>>>или здесь особый struct?
VD>>Есть только один тип в котором по умолчанию поля public — это вхождение вариантов. Во всех стальных местах по умолчанию все члены являются private. Это соглашение всех без исключения C-подобных языков.
_C_>в С++ открытые. значит в С# стали чудить, но я на нем не пишу. но это потому что в Майкрософте народу много, чтобы всех занять придумывают раздутый синтаксис, из пальца высосанные ограничения и низкий уровень языков.
В C# не стали чудить, а просто требуют указания публичного контракта.
И правильно делают.
Кстати, в Boo и Java так тоже
VD>>Очень советую поглядеть исходники стандартной библиотеки макросов. И вообще, код компилятора и библиотек дает 99% ответов связанных с написанием макросов. Лично я учил немерл, в основном, на его основе. Например, вот код макроса написанный в индент-стиле. _C_>Смотрю регулярно, хорошо написано, но понятно не все.
Вопросы в студию.
VD>>В прочем, если можешь себя перебороть, то лучше перейти на скобочный стиль, так как только он поддерживается в IDE. Иначе с комплитом и другими сервисами IDE будут проблемы. _C_>что-нибудь милое и знакомое оставить надо. для психики лучше. и для кода тоже.
_C_>еще вот не понял как простые стандартные фиксированные массивы создаются (которые в шарпе типа System.Int32[]) _C_>есть ли короткая запись для такого типа? Статьи Nemerle читали?
C#
Nemerle
var ary = new int[1];
ary[0] = 42;
var ary = new int[] { 42 };
var ary = new [] { 42 };
// явное указание типа переменнойint[] ary = new [] { 42 };
// массив массивов (вложенный массив)int[][] ary = new[] { new[] { 42 } };
var ary = new[] { new[] { 42 }, new[] { 33, 1 } };
// многомерные массивыvar ary = new[,] { { 42, 1 }, { 33, 2 } };
Console.WriteLine(ary[0, 0]);
Здравствуйте, _nn_, Вы писали:
__>А этот VariantOption когда стоит использовать вместо option ? __>Только для производительности ? Ведь для юзер кода option должно хватить.
Тогда же, когда стоит использовать структуры вместо классов — то есть когда нету боксинга.
__>>Вообще, ничего сложно в написании "!= null" , "!= 0" совершенно нет. __>>А если использовать Pattern Matching то вообще практически не нужно.
я бы предпочел не писать, это может компилятор. а то типы выводит, а "!= null" сами напишем!
пожалеем, дадим отдохнуть.
VD>Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности.
В Воо все поля в структуре public по умолчанию, в классах private.
VD>>>Очень советую поглядеть исходники стандартной библиотеки макросов. И вообще, код компилятора и библиотек дает 99% ответов связанных с написанием макросов. Лично я учил немерл, в основном, на его основе. Например, вот код макроса написанный в индент-стиле. _C_>>Смотрю регулярно, хорошо написано, но понятно не все. __>Вопросы в студию.
вот это что дает и что за global ?
($("_N_continue" : global)
вот это непонятно что в match получается
match (cases)
{
| <[ match ($_) { ..$cases } ]> =>
Здравствуйте, _Claus_, Вы писали:
__>>Кстати, в Boo и Java так тоже
_C_>В Воо все поля в структуре public по умолчанию, в классах private.
Да, все таки структурах публичные.
Похоже и в F# также.
VD>>>>Очень советую поглядеть исходники стандартной библиотеки макросов. И вообще, код компилятора и библиотек дает 99% ответов связанных с написанием макросов. Лично я учил немерл, в основном, на его основе. Например, вот код макроса написанный в индент-стиле. _C_>>>Смотрю регулярно, хорошо написано, но понятно не все. __>>Вопросы в студию.
_C_>вот это что дает и что за global ?
_C_> ($("_N_continue" : global)
Это создает метку. Если не ошибаюсь global нам поможет создать уникальное имя.
Это тут к статьям о макросах и цитировании.
В Nemerle есть уникальный способ решения выхода из множества циклов и нет необходимости в операции goto.
Работает на базе блоков:
Тут все просто.
Создаем блок _N_break, и вызываем локальную функцию, в которой есть блок _N_continue.
Если вызовем "break" то выйдем из блока, т.е. из цикла.
Если вызовем "continue", то выйдем из внутреннего блока, а потом снова вызовем локальную функцию, т.е. следующую итерацию цикла.
Здравствуйте, _nn_, Вы писали:
VD>>Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности. __>А этот VariantOption когда стоит использовать вместо option ? __>Только для производительности ? Ведь для юзер кода option должно хватить.
Для нее, для родной. Лично я по причине оверхэда option[T] использую редко.
ValueOption[T] дает совсем незаметный оверхэд. Так что его можно использовать где угодно.
Я тут подумал... ValueOption[T] можно попробовать усовершенстовать еще сильнее. Создать версию для объектов, которая в качестве признака null будет использовать самое поле со значением. Тогда оверхэда по памяти вообще не будет. Вот только придется называть ее по другому. Например ObjectOption[T]. Жаль типы нельзя перегружать.
VD>>Ну, дык соберите команду тех кого интересует этот режим и устраните этот недочет.
__>Можно попробовать, только боюсь ни у кого на это нет времени \
Ну, а что же вы хотите? У меня тоже не было времени. Но было желание. Я сел и начал делать. На все у меня тоже времени не хватит.
__>Да и для меня скобочки не смертельный вариант. __>В С-подобных языках вообще выбора нет
Вот и я о том же. Так что тот кому не нравятся скобочки может или смириться с ними, или засучить рукова и допилить интеграцию так, чтобы она поддерживала и бесскобочный синтаксис.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
__>>В C# это является ошибкой, и в Nemerle тоже. __>>Статические методы нужно вызывать напрямую через тип. _C_>Может я наивен, но смысла в этом никакого, а вред вполне ощутимый.
Смысл в этом очевидный. Компилятор выявляет ошибки и указывает программисту на это. Это из той же оперы что и необходимость объявления переменной. Физически без этого обойтись можно, но это провоцирует ошибки.
_C_>нафига использующей стороне знать детали реализации моего класса?
Статические методы не являются частью реализации класса. Выражение идущее до точки (при вызове метода) — это дополнительный параметр. Не находишь, что странно передавать функции лишний параметр?
_C_>Я могу изменить экземплярное на статическое или наоборот — вызывающий код зачем переделывать?
Если хочешь чтобы вызовы статических методов выглядели как экзеплярные, делай их методами-расширениями.
Только при этом логично было бы, чтобы статический метод получал бы значение объекта в первом параметре. Иначе будет лишний (неиспользуемый параметр).
Ну, а если метод не обращается к типу к которому он объявлен, то с огромной вероятностью этот метод лежит не там где следовало бы. Таким методам место в отдельных модулях.
_C_>потому что в Майкрософте им виднее ..
В МС тоже не идиоты сидят. Проектируя C# в МС сделали многое чтобы сделать язык более безопасным (не допускающим случайных ошибок). К сожалению, без проблем тоже не обошлось и косяки в язык добавили. Например, оператор as. Но в целом дизайн C# лучший из мэйстрим-языков.
При проектировании Nemerle концепция недопущения случайных ошибок была поставлена во главу угла. В процессе работы над языком было выкинуто ряд решений которые могли приводить к случайным ошибкам. На сегодня немерл один из самых устойчивых к ошибкам языков из практически применимых ЯП.
Ломать это с какими либо целями никто не будет. Почти уверен, что со временем ты сам согласишься, что в Немреле все очень продумано.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.