Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
Отличный обзор, благодарю.
ощибка: Intelli Science а надо IntelliSense
Спасибо большое за обзор :) только не generetic, a generic.
поправьте «обоготился»
Спасибо, очень компактно и по делу.
>>представлением вызовов методов или бинарных операций в виде дерева
Сложновато завернули. Давайте напишем это как: компилятор строит AST для участка программы и сохраняет его в метаданных, которые потом можно разобрать. Кстати, такое было возможно и в .net 3 (Linq2XXX был построен как раз на нем), только сильно урезано.
>> Новое в generic
Очень сложно пояснили; это называется ковариантностью относительно параметризующих типов. В предыдущем фреймворке она была только для System.Array; теперь и для generic'ов можно указать, нужна она или нет.
>>представлением вызовов методов или бинарных операций в виде дерева
Сложновато завернули. Давайте напишем это как: компилятор строит AST для участка программы и сохраняет его в метаданных, которые потом можно разобрать. Кстати, такое было возможно и в .net 3 (Linq2XXX был построен как раз на нем), только сильно урезано.
>> Новое в generic
Очень сложно пояснили; это называется ковариантностью относительно параметризующих типов. В предыдущем фреймворке она была только для System.Array; теперь и для generic'ов можно указать, нужна она или нет.
>> Я рад дефолтным значениям, и постараюсь не использовать функциональность именованных параметров.
А я — наоборот :)
А я — наоборот :)
удачи в общении с build team и другими программистами, которые понятия не имеют о том, что нельзя менять имена их параметров…
Ножи тоже опасны, но их же выпускают :)
Я думаю, что такая ситуация пойдет во благо и заставит людей внимательнее относиться к именованию параметров. Ну и потом, это все отлавливается на этапе compile-time, т.е. до еще до запуска первичных unit-test'ов.
Вот с dynamic будет сложнее )
Я думаю, что такая ситуация пойдет во благо и заставит людей внимательнее относиться к именованию параметров. Ну и потом, это все отлавливается на этапе compile-time, т.е. до еще до запуска первичных unit-test'ов.
Вот с dynamic будет сложнее )
> Ну и потом, это все отлавливается на этапе compile-time
вот я и говорю: те кто будут использовать, например вашу библиотеку очень будут удивлятся. У вас крунпый проект? Больше 10тыс человеко часов? Быть может вы не сталкивались с проблемами сборки, конфликтов версий и т.д., а я лично сыт ими уже по горло…
вот я и говорю: те кто будут использовать, например вашу библиотеку очень будут удивлятся. У вас крунпый проект? Больше 10тыс человеко часов? Быть может вы не сталкивались с проблемами сборки, конфликтов версий и т.д., а я лично сыт ими уже по горло…
У нас крупный проект, приближается к 10тыс )
Существует такая вещь, как публичный контракт на библиотеку. Думаю, что он в основном решает эту проблему. То, что код с именованными параметрами становится куда читабельнее, чем без них, перевешивает указанный вами недостаток, но это мое имхо.
Я пишу на с#, и за последние полгода я не помню, чтобы пришлось переименовать параметры public или protected метода в сборке, поставленной на продакшн или в stable-ветке.
Кроме того, в .net достаточно хорошо работает версионирование сборок.
Когда я писал на с и с++, да еще и участвовал в build-team, со сменой интерфейса приходиломь помудохаться, да ) Но с .net этих трудностей не наблюдается. Пока )
Существует такая вещь, как публичный контракт на библиотеку. Думаю, что он в основном решает эту проблему. То, что код с именованными параметрами становится куда читабельнее, чем без них, перевешивает указанный вами недостаток, но это мое имхо.
Я пишу на с#, и за последние полгода я не помню, чтобы пришлось переименовать параметры public или protected метода в сборке, поставленной на продакшн или в stable-ветке.
Кроме того, в .net достаточно хорошо работает версионирование сборок.
Когда я писал на с и с++, да еще и участвовал в build-team, со сменой интерфейса приходиломь помудохаться, да ) Но с .net этих трудностей не наблюдается. Пока )
мне кажется, что решарпер сможет с легкостью разрефакторить переименование параметра.
с чего это вы взяли что вам дадут чужой код менять (да и вообще код кто вам даст), чтобы изменить название своего параметра?
1. Делаем FindUsages.
2. Если видим в списке код, за который отвечает ваш коллега, подходим к нему и согласовываем вопрос, лучше конечно таких ситуаций избегать, поскольку усиливается связность различных частей кода. То есть стараться работать над частями, которые взаимодействуют друг с другом по заранее оговоренным наборам интерфейсов, которые каждый день меняться не должны.
3. Если мы видим только свой код, меняем имя без последствий одним нажатием.
2. Если видим в списке код, за который отвечает ваш коллега, подходим к нему и согласовываем вопрос, лучше конечно таких ситуаций избегать, поскольку усиливается связность различных частей кода. То есть стараться работать над частями, которые взаимодействуют друг с другом по заранее оговоренным наборам интерфейсов, которые каждый день меняться не должны.
3. Если мы видим только свой код, меняем имя без последствий одним нажатием.
рассказать вам про рефлексию в чистом виде, IoC контейнеры, конфигурируемые через config файлы и т.д.?
и вообще FindUsage не решит проблему, даже при условии «обычного использования библиотек», т.к. из свей библиотеки вы их просто «не видите» (не видите зависимости)
и вообще FindUsage не решит проблему, даже при условии «обычного использования библиотек», т.к. из свей библиотеки вы их просто «не видите» (не видите зависимости)
Да спасибо, я сам spring использую и библиотеки, конфигурируемые через xml пишу.
//
И проблемы с переименованием параметров в случае использования инъекций объектов — это не проблемы конкретно переименования параметров, это проблемы также и переименования типов, сигнатур методов итд, — то есть все те проблемы, из-за которых идея dependency injection не является идеальной. Вы можете так же ругаться на переименованный класс, который нужно искать по config-файлам, чтобы заменить строчку с названием типа или фактори метода. В общем, это не есть проблема переименования параметров, а более общая.
//
И проблемы с переименованием параметров в случае использования инъекций объектов — это не проблемы конкретно переименования параметров, это проблемы также и переименования типов, сигнатур методов итд, — то есть все те проблемы, из-за которых идея dependency injection не является идеальной. Вы можете так же ругаться на переименованный класс, который нужно искать по config-файлам, чтобы заменить строчку с названием типа или фактори метода. В общем, это не есть проблема переименования параметров, а более общая.
это понятно, а если сборки разные? в смысле есть к примеру какая то сборка, разрабатываемая одной командой, и другая другой, исходниками не пользуются, а используют уже сами сборки, и вот так вот одна команда может срывать билды другой команде грандиозным рефакторингом ;)
Только что ответил камраду чуть выше по аналогичному вопосу: habrahabr.ru/blogs/net/60206/#comment_1643355
> Expression<Func<int, bool>> exprTree = num => num < 5;
…
> В этом примере мы сначала описываем лямбда выражение x=>x<5, а затем при помощи объектов от Expression Trees разбираем данное выражение.
я бы на вашем месте использовал не x как название переменной, а num. Именно это название в примере. Новичка это может просто запутать.
хороший обзор — спасибо
…
> В этом примере мы сначала описываем лямбда выражение x=>x<5, а затем при помощи объектов от Expression Trees разбираем данное выражение.
я бы на вашем месте использовал не x как название переменной, а num. Именно это название в примере. Новичка это может просто запутать.
хороший обзор — спасибо
Новый dynamic тип может внести много неразберихи, особенно при его некорректном использовании. Плюс очень сильно пострадает IntelliSense. Надеюсь в MSDN напишут рекомендации по его использованию…
И ни в коем случае не говорить об этом ключевом слове студентам и индусам… а то начнут экономить на переменных =(
а вы знаете, очень похоже на VB с автоматическим IDispatch… очено огромный геморой в общем. Вроде все работает и компилируется, а потом вылетает в самых интимных операциях… ИМХО очень плохое слово сделали. Так, глядишь дойдет и до отмены типизации…
Круто круто!!! Люблю .NET!!! Спасибо за обзор.
мдя… синтаксис c# всё усложняется и усложняется.
получается жуткая смесь из строго типизированного и слабо типизированных языков. это дайт ещё больше возможностей индусским программистам усложнять и запутывать код.
имхо smalltalk был и остаётся наиболее удобным языком для написания кода.
спасибо за обзор :)
получается жуткая смесь из строго типизированного и слабо типизированных языков. это дайт ещё больше возможностей индусским программистам усложнять и запутывать код.
имхо smalltalk был и остаётся наиболее удобным языком для написания кода.
спасибо за обзор :)
По-моему, семантика C# всё больше и больше приводится к семантике QiuickBasic. Уже появилось необязательное приведение типов… :)
С другой стороны:
С другой стороны:
Появились новые типы, как например, BigInteger — теперь не нужно для лабораторных работ студентам писать свои классы для работы с большими числами ;), SortedSet— класс представляет собой самостоятельное балансированное дерево, которое сохраняет данные в отсортированном порядке после вставки, удаления и поиска. — аналоги того, что класс java.math.BigInteger
было в Java 1.1, а интерфейс java.util.SortedSet в Java 1.2 были изобретены десять лет назад.
Кто там главный ахитектор у Microsoft по языку C#? Всё тот же Андерс Хейлсберг, который бросил заниматься Delphi и WFC s в 1996 году?
С другой стороны:
было в Java 1.1, а интерфейс java.util.SortedSet в Java 1.2 были изобретены десять лет назад.
Появились новые типы, как например, BigInteger — теперь не нужно для лабораторных работ студентам писать свои классы для работы с большими числами ;), SortedSet— класс представляет собой самостоятельное балансированное дерево, которое сохраняет данные в отсортированном порядке после вставки, удаления и поиска.— аналоги того, что класс java.math.BigInteger
было в Java 1.1, а интерфейс java.util.SortedSet в Java 1.2 были изобретены десять лет назад.
класс Integer, с ограничением на размер хранимого числа пропорциональным размеру оперативной памяти, появился в smalltalk 30 лет назад ;)
и что в этом такого? никто же не говорит, что это какие то инновации. значение параметров по умолчанию в методах есть наверное уж лет 40, ну и что?
Что в них такого?
Классы BigInteger и BigDecimal используются при работе с Java Cryptography Architecture (JCA/JCE), не говоря уж о научных математических вычислениях.
Классы BigInteger и BigDecimal используются при работе с Java Cryptography Architecture (JCA/JCE), не говоря уж о научных математических вычислениях.
я не спрашиваю что в них такого, я понимаю что они нужны :) я спрашиваю, ну и что с того, что они там были?
ну просто в .NET раньше их не было. c# сам по себе намного младше Java, имхо: Java для него как старший брат, что то он от него и берет.
BigInteger пришел как раз с F#, как раз для математических вычислений. Раньше, может, не так требовалось, не знаю.
ну просто в .NET раньше их не было. c# сам по себе намного младше Java, имхо: Java для него как старший брат, что то он от него и берет.
BigInteger пришел как раз с F#, как раз для математических вычислений. Раньше, может, не так требовалось, не знаю.
да ведь никто не обязывает использовать все фичи самых новых версий C#, фундаментом все равно остается старый добрый синтаксис C# 2.0
Только из-за значений по умолчанию, пожалуй, перейду на C#4 с C#2.
Expression появились в 3.5 вместе с LINQ, если я не ошибаюсь.
Ой, как всё вкусно!
И где вы были со своим биг интом, когда я месяц наза домашку про НТФС писал?
И где вы были со своим биг интом, когда я месяц наза домашку про НТФС писал?
кстати
System.Diagnostics.Contracts кто-то щупал?
у меня не работает ни статическая проверка, ни в рантайме
или они в бете не доделали?
System.Diagnostics.Contracts кто-то щупал?
у меня не работает ни статическая проверка, ни в рантайме
или они в бете не доделали?
Я с ними игрался, но не в это бете, а на VS2008 и .NET 3.5 — все работало: habrahabr.ru/linker/go/59217/
Я правильно понял, что по дефолту в FW будут IronRuby и IronPython?
Обзор очень интересный, спасибо автору!
А вот по теме C#. Не проще было вместо него сделать основным языком какой нибудь Ruby и забыть жесткую типизированность как страшный сон? Ведь к тому и движется все, только с попыткой обратной совместимости и багажом тяжелой наследственности.
А вот по теме C#. Не проще было вместо него сделать основным языком какой нибудь Ruby и забыть жесткую типизированность как страшный сон? Ведь к тому и движется все, только с попыткой обратной совместимости и багажом тяжелой наследственности.
Бред присутствует в каждом вашем слове, учиться никогда не поздно, может поймете, что ж. типизация полезна
это когда она полезна? код написанный на c# напоминает большую мешанину. его тяжело читать из-за операций по приведению типа.
аргументируйте!
аргументируйте!
Жесткая типизация позволяет отсеять некоторые ошибки на этапе компиляции и это главный аргумент
это стандартная отмазка. найдите что-нибудь по-серьёзней.
не прокатывает — во-первых только «некоторые».
во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
в третьих — постоянное приведение типов в c# никак не спасает от каста не того объекта не к тому типу. вы пишете программы без кастов? хха!
в четвёртых — пишите юнит тесты. ваш код станет лучше.
ещё аргументы есть? (что-то поспорить хочется, пятница как-никак :) вы уж извините)
не прокатывает — во-первых только «некоторые».
во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
в третьих — постоянное приведение типов в c# никак не спасает от каста не того объекта не к тому типу. вы пишете программы без кастов? хха!
в четвёртых — пишите юнит тесты. ваш код станет лучше.
ещё аргументы есть? (что-то поспорить хочется, пятница как-никак :) вы уж извините)
>>не прокатывает — во-первых только «некоторые».
идеален только Б-г :)
>>во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
Есть ощущение, что вы не видели программы таких размеров, что пройти по всем веткам становится крайне затруднительно. Unit-test'инг никто не отменял, но все-таки.
>>в третьих — постоянное приведение типов в c# никак не спасает от каста не того объекта не к тому типу. вы пишете программы без кастов? хха!
Пишу. Посчитал специально. За последние написанные ~6000 строк не пользовался ни разу
>>в четвёртых — пишите юнит тесты. ваш код станет лучше.
здесь категорически согласен и не спорю, портя вам удовольствие от пятницы, уж извините :)
идеален только Б-г :)
>>во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
Есть ощущение, что вы не видели программы таких размеров, что пройти по всем веткам становится крайне затруднительно. Unit-test'инг никто не отменял, но все-таки.
>>в третьих — постоянное приведение типов в c# никак не спасает от каста не того объекта не к тому типу. вы пишете программы без кастов? хха!
Пишу. Посчитал специально. За последние написанные ~6000 строк не пользовался ни разу
>>в четвёртых — пишите юнит тесты. ваш код станет лучше.
здесь категорически согласен и не спорю, портя вам удовольствие от пятницы, уж извините :)
> во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
Вы видели «программы», сборка которых занимает несколько часов?
Вы видели «программы», сборка которых занимает несколько часов?
+1. И многие вещи в тестах также проверяются на уровне соответствия строгих типов, что очень удобно.
>>его тяжело читать из-за операций по приведению типа.
Какой-то вы неправильный код видели, наверное.
Какой-то вы неправильный код видели, наверное.
Вы видимо читаете слова, а в смысл все одно не вникаете. Ж. типизация и правда полезна при решении определенного класса задач. Но нафига ее мешать с динамической? Ведь на то и есть CLR чтобы разные части можно было писать на разых языках. Нужна ж. типизаци — пишем на C# или C++, а если хотим динамики на ruby/python. Но зачем пытаться объединить в одном языке диаметрально противоположные подохды?!
з.ы. писал и на ruby и на C# 2.0 и C# 3.0 так что знаю о чем говорю.
з.ы. писал и на ruby и на C# 2.0 и C# 3.0 так что знаю о чем говорю.
даже CLR не спасает.
например класс Dictionary. тот, который без шаблонов — использует аргументы класса object = касты.
например класс Dictionary. тот, который без шаблонов — использует аргументы класса object = касты.
для того чтобы касты проходили нормально существуют is и as.
По мне тут дело другое. Просто все зависит от языка и от задачи. Многие, знающие C# очень много программируют на JS, один язык типизированный (уже можно сказать метатипизированный наверное), другой нет, но ничего же страшного и с тем и с тем справляются.
В c# ввели dynamic, но он нужен только для определенного вида задач. В прошлой версии был var, но никто же не стал его использовать везде, где только можно, тут такое же дело. В некоторых задачах он будет вероятно полезен- с теми же COM Interop.
Я, честно говоря, уж очень мало когда использовал языки, вроде Ruby (но надеюсь пример с JS близок к нему), когда то писал что то вроде плагинов для xchat и foobar и еще чего то, не более того. Но мне кажется, просто, что такие языки не очень то подходят для ООП, в отличие от типизированных, вроде C# — хотя может быть это дело привычки. На js можно спокойно делать объекты, но в районе создания некоторых контролов, загнать туда бизнесс логику по мне так трудная задача. Можно посмотреть с другой стороны — глянем на c/c++ совместно с WINAPI32 и близлежащем, если там не будет типизации, то ох как сложно будет все эти структуры инициализировать. В общем буду рад услышать другое мнение, действительно интересная тема.
По мне тут дело другое. Просто все зависит от языка и от задачи. Многие, знающие C# очень много программируют на JS, один язык типизированный (уже можно сказать метатипизированный наверное), другой нет, но ничего же страшного и с тем и с тем справляются.
В c# ввели dynamic, но он нужен только для определенного вида задач. В прошлой версии был var, но никто же не стал его использовать везде, где только можно, тут такое же дело. В некоторых задачах он будет вероятно полезен- с теми же COM Interop.
Я, честно говоря, уж очень мало когда использовал языки, вроде Ruby (но надеюсь пример с JS близок к нему), когда то писал что то вроде плагинов для xchat и foobar и еще чего то, не более того. Но мне кажется, просто, что такие языки не очень то подходят для ООП, в отличие от типизированных, вроде C# — хотя может быть это дело привычки. На js можно спокойно делать объекты, но в районе создания некоторых контролов, загнать туда бизнесс логику по мне так трудная задача. Можно посмотреть с другой стороны — глянем на c/c++ совместно с WINAPI32 и близлежащем, если там не будет типизации, то ох как сложно будет все эти структуры инициализировать. В общем буду рад услышать другое мнение, действительно интересная тема.
Если честно, меня удивила фраза заменить с# на Ruby. Хотя сейчас вижу, что это не более чем сравнение.
а для чего, с практической точки зрения, полезны Dynamic Objects?
Всё не просто в этом мире
Всё исправил C4: )
Всё исправил C4: )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новые возможности .NET 4.0: C# 4.0