Предположим теперь, что двигателей в этом примере есть всего три (да, именно три экземпляра), а транспортных средств – много, но они все могут по несколько раз использовать один и тот же двигатель, разделяя его между собой. (Это хороший пример с точки зрения кода, но отвратительный точки зрения логики реального мира: переставлять двигатель с одной машины на другую — весьма сомнительное удовольствие.)
Эээээ. С точки зрения кода этот пример не особо лучше "реального мира". Это не "переставлять" двигатель. Это значит: к одному двигателю прицепить все машины в мире.
var car1 = new Car();
var car2 = new Car();
car1.Move();
Пара пакетов анализаторов на 95% покрывают рефакторинги решарпера
Я особо не интересовался этим, так что не готов дискутировать. Допускаю, что действительно для всего можно найти замену.
То вам нужна каждая-каждая фича, то «мои потребности он покрывает».
Каждая-каждая применимая. Мне не нужна поддержка JSX, например )
Из того, чем я пользовался в студии на работе, мне не хватает разве что поддержки T4, красиво мигающих квадратиков в R# build и дебаггера. Зато получил крутую поддержку VCS и отсутствие тормозов.
На личных проектах еще жалко continuous testing, но там я могу и студию использовать, т.к. проекты мелкие и не тормозит.
потому что это более новая, современная, вдохновляющая среда разработки, а не из-за производительности.
Не без этого. Доля вдохновления в этом тоже есть, но в основном все-таки тормоза достали. На мелких проектах действительно пользуюсь просто из энтузиазма, потому что в студии не тормозит и фич пока больше.
Остальное есть или добавляется тривиальными анализаторами/расширениями.
Одного супер-решения я не видел, а искать и ставить условные 10 расширений, которые между собой еще и конфликтовать могут и где-то друг-друга дублируют, не особо хочется. Решарпер все же является единым продуктом. Да и вряд ли на некоторые фичи есть аналоги. Не стоит забывать о том, что решарпер пишут вроде уже 10 лет и там накоплена огромная куча всяких тулов.
Но, конечно, я не спорю с тем, что кому-то будет достаточно голой студии и нескольких мелких экстеншнов. Тогда нет смысла ставить решарпер.
А вы не думали, что может быть тормоза этой фича у вас отнимают больше времени и нервов, чем экономит? Мне кажется, SWA именно к такому относится.
Это вполне возможно, фича тяжелая, но и полезная. Можно от нее отказаться и улучшить перформанс ценой потери части возможностей, а можно поставить райдер и сохранить фичу включенной. Я за второй вариант ) В райдере сейчас есть далеко не все, что дает решарпер, но мои потребности он покрывает. Ради остального я готов раз в неделю запустить студию.
Голую 2017. Как я говорил выше, у R# не так много много фич, которых нет в 2017
Серьезно? Куча рефакторингов, билд, юнит-тесты (в студии это есть, но неудобно), continuous testing, крутые навигации и поиск, посветка всяких интересных ошибок, code cleanup, генерация кода, поддержка JS, CSS, HTML с теми же самыми анализами, рефакторингами и т.п. Если говорить о райдере, то еще поддержка VCS, интеграция с issue trackers.
Я понимаю, что многие этим всем не пользуются, но я вот люблю выжимать из инструментов все, на что они способны. Когда я вижу новую фичу, которую возможно использовать на моих проектах и которая хоть немного что-то улучшает/упрощает — я начинаю ей пользоваться. Даже если она экономит мне жалкие 5 минут в день.
Мне кажется, здесь вина именно R#
Не исключаю такой возможности. Но я рассуждаю так: у меня есть на выбор два инструмента, дающих примерно одинаковые возможности. Первый работает плохо, второй хорошо. Очевидно, я выберу второй. И по существу мне без разницы, чья вина в том, что первый плох. Может, это криво написана студия. Может, решарпер криво интегрирован со студией. Может, решарпер сам по себе кривой. Мне это неинтересно, я пользуюсь ими в связке и смотрю как на единое целое.
Но учитывая, что VS + R# работает фигово, а IDEA + R# работает хорошо, я больше склоняюсь к тому, что что-то плохо в самой студии. Может, я и неправ.
Единственное, чего мне сейчас недостает в райдере — сравнимого со студией (особенно при использовании OzCode) дебаггера. В райдере он менее удобен и функционален, и пока еще там есть феерические баги.
Для чего? Вы имеете ввиду голую 2017, или с тем же самым, чем я пользуюсь в 2013?
А что есть в Rider аналог SWA?
View->Tool Windows->Errors in solution открывает такое же окошко SWA, что и в студии. Это ровно та же самая фича.
Не очень понял, что вы имеете ввиду, но да, загрузка проектов была оптимизирована.
Я вот об этом нововведении 2017: Reload All Projects has been replaced with Reload Solution to support better performance of switching branches external to VS. Если действительно оптимизировали, то да, круто, но надо пробовать.
Во всех ваших претензиях следует заменить «студия» на «студия с R# и Solution-wide analysis».
Да, но накой мне сравнивать голую студию с райдером, если это абсолютно разный уровень по фичам? Это как nokia 3310 с айфоном сравнивать, если утрировать. Я сравниваю два варианта, предоставляющих мне одинаковые возможности по функционалу.
решарперовский Solution-wide analysis тормозит так, что его просто невозможно использовать. Ну и немного ССЗБ.
Удивительно. В студии тормозит, в райдере не тормозит. Может, дело в студии?
Но в VS 2017 этой проблемы практически нет, проекты перезагружаются очень быстро.
Вы про кнопку "перезагрузить солюшн" вместо "перезагрузить проект"? Или они таки перезагрузку отдельного проекта оптимизировали?
Вам не кажется, что как минимум некорректно сравнивать производительность голой студии и студии_с_решарпером/райдера? Очевидно, решарпер будет влиять на производительность из-за 100500 фич, анализов и т.п. Если та же скорость загрузки солюшна в голой студии и райдере одинаковая, то это плохие новости для студии, поскольку райдер за это же время делает гораздо больше и дает гораздо больше фич.
По сути. Я на работе пользуюсь райдером как основной IDE уже около трех месяцев. В солюшне около 200 проектов. До этого была студия 2013 + решарпер с включенными тяжелыми фичами (solution-wide analysis, r# build, вот это все). В 2015 на моем проекте было еще хуже по памяти, пришлось вернуться на 2013.
Наблюдения:
От запука студии до возможности начать работу запросто проходило 5 минут, до этого дикие тупняки или просто зависание UI. В райдере можно работать через минуту, если не меньше.
Студия во время работы периодически тупила и зависала на несколько секунд даже просто при вводе текста. Если запускаешь сборку, вообще лучше ничего не трогать и не кликать в интерфейсе — виснет. Райдер в процессе работы не зависает, сборка почти не влияет на производительность (справедливости ради, последний eap пару раз в день полностью вешается секунд на 5-10, в предыдудщих такого не было).
В студии сделать пулл или переключить ветки — это боль и скорее всего необходимость выгружать солюшн и загружать заново (см п.1), иначе виснет от минуты до бесконечности. Райдер мгновенно подтягивает изменения.
Студия в фоне иногда запросто выжирала 80-90% цпу. Ты сидишь в браузере, а там где-то что-то происходит и тормозит вообще все. Две запущенных студии на пару выжирали 100% цпу.
Студия падала 1-5 раз в день, видимо из-за OutOfMemory.
Как видите, мой опыт полностью противоположен вашему, мне райдер существенно повысил эффективность работы и сохранность нервов.
В JetBrains не работаю, за положительные отзывы от них денег не получаю.
class A { public static string inf; }
class A2 : A { public static new string inf; }
A.inf = "a";
A2.inf = "a2";
Хотя решение не очень красивое, конечно.
Если в более общем виде, то так
using System;
class Meta
{
string _meta;
public Meta(string meta)
{
_meta = meta;
}
public override string ToString()
{
return _meta;
}
}
class A
{
public static Meta meta;
}
class A1 : A
{
public static new Meta meta;
}
class A2 : A
{
public static new Meta meta;
}
public class Program
{
public static void Main()
{
A1.meta = new Meta("a1");
A2.meta = new Meta("a2");
Console.WriteLine(A.meta);
Console.WriteLine(A1.meta);
Console.WriteLine(A2.meta);
}
}
Может, стоило бы вообще убрать такого рода информацию из статических полей и организовать доступ к ней как-то еще. Например, importantInfoProvider.Get().Width. А внутри по типу определять, что вернуть. Не думаю, что решение через статику — единственное или лучшее возможное.
у них общий набор типовых характеристик например
static Name, Type, Width, Height, у каждого класса свои значения. И возможно они зависит от расчета в родителе.
Почему бы не сделать какое-нибудь статическое свойство Meta, куда в статическом конструкторе положить экземпляр класса характеристик с нужными значениями, привязкой к базовым характеристикам и т.п.? Будет у вас A1.Meta.Width, например. Реализация чуть сложнее, но снаружи разницы особо нет. Можно добавить еще экземплярное свойство Meta, которое просто возвращает значение статического. Тогда и на экземплярах удобно будет звать статику.
Как удобней писать? в месте каждого вызова A1.Width() или просто Width()?
По мне, удобнее писать одни и те же вещи одинаково, и разные вещи по-разному. Именно поэтому для статики писать везде A1.Width лучше, чем где-то A1.Width, а где-то a.Width (который статический, но пишется почему-то как экземплярный).
О каком единообразии может идти речь, когда это фундаментально разные вещи? Такое единообразие мозг сломает в момент. И еще раз, нельзя называть метод статическим, если он требует наличия созданного экземпляра класса для своего вызова.
Можно вести речь о том, чтобы заиметь в языке что-то вроде "класса как объекта", и писать, например:
class A { static virtual void foo() {...}}
class B : A { static override void foo() {...}}
Class<A> a = A;
a.foo(); // вызывает A.foo()
a = B;
a.foo(); // вызывает B.foo()
a = (new B())->class;
a.foo(); // вызывает B.foo()
О чем и речь. Мы получили экземплярный виртуальный метод. Зачем тогда делать статический метод виртуальным, чтобы он вел себя ровно так же, как экземплярный? Причем это полное нарушение концепции статических методов.
Скорее всего у вас нет специфических знаний по вызовам виртуальных функций в рантайме.
Так просветите, интересно же.
Мне вот кажется, что это вы не знаете, как CLR хранит ссылки на объекты и сами объекты. Если бы со ссылкой связывалась информация о типе объекта, тогда да, проблем нет. Но информации о типе у ссылки нет.
>> Все хорошо — тип объекта то есть. Вот по типу и вызовет.
Вот в этом и проблема. Типа объекта нет.
1. Во время компиляции конкретный тип объекта неизвестен.
2. Во время исполнения у вас, грубо говоря, в памяти 0 (т.е. null). Метаданные связываются с конкретным экземпляром класса, а не со ссылкой на него. Соответственно, по null ссылке вы никак не узнаете, на экземпляр какого типа она указывает.
>> А если (B(null)).info(); то от B; Что вас смущает?
Здесь — ничего. А если так:
A a = new B();
a.info();
Должен вызваться метод A.info() или B.info()?
>> Откуда null, в статик функции? Даже у виртуальной.
А как CLR должен в рантайме определить, виртуальную статическую функцию какого класса вызывать? Видимо, по экземпляру класса. Если он null, все плохо. Если не по экземпляру, то как еще?
Какая? Класса A или класса B?
Если речь о том, чтобы сделать две одинаково работающих возможности вызова статик метода: A.info() и a.info(), то действительно работать будет. Только непонятно, зачем.
Но о виртуальных статических методах можно забыть из-за возможного null.
>> Вызов любой функции может дать NullReferenceException.
>> А самое забавное, что вызов статической функции НИКАК не может вызвать NullReferenceException.
Вы противоречите сами себе.
class A { public static virtual info() {...}; }
class B: A { public static override info() {...}; }
A a = null;
a.info(); // что произойдет по-вашему?
Например тем, что объект может оказаться null. Ловить NullReferenceException на статических методах — не очень большая радость. И вообще тогда какие отличия от экземплярных методов, кроме потери доступа к this в теле метода?
Судя по тому, как припекло вашей активности, утверждение «Мне абсолютно фиолетевен эсшарп» несостоятельно. У вас такие яркие негативные чувства вызывает то, что в вашем родном городе кто-то пишет на шарпе?
Эээээ. С точки зрения кода этот пример не особо лучше "реального мира". Это не "переставлять" двигатель. Это значит: к одному двигателю прицепить все машины в мире.
Все дружно поедут?
Я особо не интересовался этим, так что не готов дискутировать. Допускаю, что действительно для всего можно найти замену.
Каждая-каждая применимая. Мне не нужна поддержка JSX, например )
Из того, чем я пользовался в студии на работе, мне не хватает разве что поддержки T4, красиво мигающих квадратиков в R# build и дебаггера. Зато получил крутую поддержку VCS и отсутствие тормозов.
На личных проектах еще жалко continuous testing, но там я могу и студию использовать, т.к. проекты мелкие и не тормозит.
Не без этого. Доля вдохновления в этом тоже есть, но в основном все-таки тормоза достали. На мелких проектах действительно пользуюсь просто из энтузиазма, потому что в студии не тормозит и фич пока больше.
Одного супер-решения я не видел, а искать и ставить условные 10 расширений, которые между собой еще и конфликтовать могут и где-то друг-друга дублируют, не особо хочется. Решарпер все же является единым продуктом. Да и вряд ли на некоторые фичи есть аналоги. Не стоит забывать о том, что решарпер пишут вроде уже 10 лет и там накоплена огромная куча всяких тулов.
Но, конечно, я не спорю с тем, что кому-то будет достаточно голой студии и нескольких мелких экстеншнов. Тогда нет смысла ставить решарпер.
Это вполне возможно, фича тяжелая, но и полезная. Можно от нее отказаться и улучшить перформанс ценой потери части возможностей, а можно поставить райдер и сохранить фичу включенной. Я за второй вариант ) В райдере сейчас есть далеко не все, что дает решарпер, но мои потребности он покрывает. Ради остального я готов раз в неделю запустить студию.
Серьезно? Куча рефакторингов, билд, юнит-тесты (в студии это есть, но неудобно), continuous testing, крутые навигации и поиск, посветка всяких интересных ошибок, code cleanup, генерация кода, поддержка JS, CSS, HTML с теми же самыми анализами, рефакторингами и т.п. Если говорить о райдере, то еще поддержка VCS, интеграция с issue trackers.
Я понимаю, что многие этим всем не пользуются, но я вот люблю выжимать из инструментов все, на что они способны. Когда я вижу новую фичу, которую возможно использовать на моих проектах и которая хоть немного что-то улучшает/упрощает — я начинаю ей пользоваться. Даже если она экономит мне жалкие 5 минут в день.
Не исключаю такой возможности. Но я рассуждаю так: у меня есть на выбор два инструмента, дающих примерно одинаковые возможности. Первый работает плохо, второй хорошо. Очевидно, я выберу второй. И по существу мне без разницы, чья вина в том, что первый плох. Может, это криво написана студия. Может, решарпер криво интегрирован со студией. Может, решарпер сам по себе кривой. Мне это неинтересно, я пользуюсь ими в связке и смотрю как на единое целое.
Но учитывая, что VS + R# работает фигово, а IDEA + R# работает хорошо, я больше склоняюсь к тому, что что-то плохо в самой студии. Может, я и неправ.
Единственное, чего мне сейчас недостает в райдере — сравнимого со студией (особенно при использовании OzCode) дебаггера. В райдере он менее удобен и функционален, и пока еще там есть феерические баги.
Для чего? Вы имеете ввиду голую 2017, или с тем же самым, чем я пользуюсь в 2013?
View->Tool Windows->Errors in solution открывает такое же окошко SWA, что и в студии. Это ровно та же самая фича.
Я вот об этом нововведении 2017: Reload All Projects has been replaced with Reload Solution to support better performance of switching branches external to VS. Если действительно оптимизировали, то да, круто, но надо пробовать.
Да, но накой мне сравнивать голую студию с райдером, если это абсолютно разный уровень по фичам? Это как nokia 3310 с айфоном сравнивать, если утрировать. Я сравниваю два варианта, предоставляющих мне одинаковые возможности по функционалу.
Удивительно. В студии тормозит, в райдере не тормозит. Может, дело в студии?
Вы про кнопку "перезагрузить солюшн" вместо "перезагрузить проект"? Или они таки перезагрузку отдельного проекта оптимизировали?
Вам не кажется, что как минимум некорректно сравнивать производительность голой студии и студии_с_решарпером/райдера? Очевидно, решарпер будет влиять на производительность из-за 100500 фич, анализов и т.п. Если та же скорость загрузки солюшна в голой студии и райдере одинаковая, то это плохие новости для студии, поскольку райдер за это же время делает гораздо больше и дает гораздо больше фич.
По сути. Я на работе пользуюсь райдером как основной IDE уже около трех месяцев. В солюшне около 200 проектов. До этого была студия 2013 + решарпер с включенными тяжелыми фичами (solution-wide analysis, r# build, вот это все). В 2015 на моем проекте было еще хуже по памяти, пришлось вернуться на 2013.
Наблюдения:
Как видите, мой опыт полностью противоположен вашему, мне райдер существенно повысил эффективность работы и сохранность нервов.
В JetBrains не работаю, за положительные отзывы от них денег не получаю.
Немного не так:
Хотя решение не очень красивое, конечно.
Может, стоило бы вообще убрать такого рода информацию из статических полей и организовать доступ к ней как-то еще. Например, importantInfoProvider.Get().Width. А внутри по типу определять, что вернуть. Не думаю, что решение через статику — единственное или лучшее возможное.
Почему бы не сделать какое-нибудь статическое свойство Meta, куда в статическом конструкторе положить экземпляр класса характеристик с нужными значениями, привязкой к базовым характеристикам и т.п.? Будет у вас A1.Meta.Width, например. Реализация чуть сложнее, но снаружи разницы особо нет. Можно добавить еще экземплярное свойство Meta, которое просто возвращает значение статического. Тогда и на экземплярах удобно будет звать статику.
По мне, удобнее писать одни и те же вещи одинаково, и разные вещи по-разному. Именно поэтому для статики писать везде A1.Width лучше, чем где-то A1.Width, а где-то a.Width (который статический, но пишется почему-то как экземплярный).
О каком единообразии может идти речь, когда это фундаментально разные вещи? Такое единообразие мозг сломает в момент. И еще раз, нельзя называть метод статическим, если он требует наличия созданного экземпляра класса для своего вызова.
Можно вести речь о том, чтобы заиметь в языке что-то вроде "класса как объекта", и писать, например:
Но вызывать статику на экземплярах — увольте.
О чем и речь. Мы получили экземплярный виртуальный метод. Зачем тогда делать статический метод виртуальным, чтобы он вел себя ровно так же, как экземплярный? Причем это полное нарушение концепции статических методов.
Так просветите, интересно же.
Мне вот кажется, что это вы не знаете, как CLR хранит ссылки на объекты и сами объекты. Если бы со ссылкой связывалась информация о типе объекта, тогда да, проблем нет. Но информации о типе у ссылки нет.
Вот в этом и проблема. Типа объекта нет.
1. Во время компиляции конкретный тип объекта неизвестен.
2. Во время исполнения у вас, грубо говоря, в памяти 0 (т.е. null). Метаданные связываются с конкретным экземпляром класса, а не со ссылкой на него. Соответственно, по null ссылке вы никак не узнаете, на экземпляр какого типа она указывает.
Здесь — ничего. А если так:
Должен вызваться метод A.info() или B.info()?
>> Откуда null, в статик функции? Даже у виртуальной.
А как CLR должен в рантайме определить, виртуальную статическую функцию какого класса вызывать? Видимо, по экземпляру класса. Если он null, все плохо. Если не по экземпляру, то как еще?
Если речь о том, чтобы сделать две одинаково работающих возможности вызова статик метода: A.info() и a.info(), то действительно работать будет. Только непонятно, зачем.
Но о виртуальных статических методах можно забыть из-за возможного null.
>> А самое забавное, что вызов статической функции НИКАК не может вызвать NullReferenceException.
Вы противоречите сами себе.
class A { public static virtual info() {...}; }
class B: A { public static override info() {...}; }
A a = null;
a.info(); // что произойдет по-вашему?
https://en.wikipedia.org/wiki/List_of_C_Sharp_software
https://www.quora.com/What-are-some-known-programs-written-in-C
тому, как припекловашей активности, утверждение «Мне абсолютно фиолетевен эсшарп» несостоятельно. У вас такие яркие негативные чувства вызывает то, что в вашем родном городе кто-то пишет на шарпе?