Как-то сомнительно звучит, если честно. Качественный муляж АК сегодня стоит $180 на Амазоне — в 2005-м, наверняка, дешевле. Настоящий же АК тогда же стоил минимум $250 за самые дешевые варианты (румынский WASR), и такую цену еще надо было поискать.
На автоматическое оружие нет специальной лицензии. Требуется оплатить особый налог ($200) при покупке, и выдается бумажка — tax stamp — которая является доказательством уплаты этого налога держателем. На каждый ствол она своя.
Ну и плюс отдельные штаты могут запретить это на свой территории, разумеется.
4.5, увы, как раз менее логичен, потому что async void (который суть чистый fire and forget — он не дает вызывающему опции подождать в принципе) все равно валит процесс. А вот async Task — теперь не валит. При этом в 4.0 поведение было одинаковое.
Имхо все же в fire and forget, последний должен быть явным, а не по умолчанию.
Значит, надо ломать. Возможно, как питон, поддерживать две ветки некоторое время.
Но любая другая стратегия — это отодвигание решения проблемы на потом. Причем, чем дольше отодвигают, тем сложнее будет решать (потому что больше сломается).
Мы с активным использованием тасков и await огребли массу проблем с неотловленными исключениями как раз из-за того, что все разработчики сидят на VS 2013 (и, соответственно, .NET 4.5), но продукт собирается в т.ч. и для VS 2010, а там может быть и .NET 4.0. Причем чаще это были даже не косяки, а просто попытка by design запустить таск в фоне и не ждать его.
После продолжительного хождения по граблям, кстати, решили, что мы не будем поддерживать 4.0 :) тем не менее, в процессе появилась пачка вспомогательных методов для того, чтобы явно управлять поведением тасков в ситуациях без await. Может, кому еще пригодится.
>> Команды без проблем могут использовать все прелести WPF. Для этого, на сколько я понимаю, Visual Studio и переписывали на WPF, чтобы командам было проще.
Не совсем. Использовать WPF можно было и до того — например, все связанное с WPF-дизайнером в VS 2008 уже было на WPF. Переписывание шелла и редактора было связано скорее с желанием уйти от старого и трудноподдерживаемого Win32-кода, ну и заодно получить профит в виде themability, поддержки high-DPI, и тому подобных штук. Для авторов расширений это упростило некоторые вещи за счет того, например, что главный message pump в VS стал понимать некоторые WPF-специфичные вещи, но это было не столь принципиально.
При этом в VS осталось полно кода на Win32 и WinForms — задачу переписать все разом никто не ставил. Вот картинка с состоянием дел на момент релиза VS 2010:
Сейчас WPF стало больше, а остального — меньше (напр., Solution Explorer уже два релиза как WPF, опять же новый UI для тестов...). Плюс появились куски на HTML5. Хотя HTML там в принципе был и раньше — если кто задавался вопросом, почему визарды для C++-проектов позволяют выделять произвольный текст в диалоге мышкой, то вот как раз поэтому.
>> Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.
И тогда, и сейчас — VS Platform, в котором несколько команд, на самом деле. Редактор на WPF переводила его же команда, а всем остальным заведовал VS Platform Shell team.
Насчет остального же у вас неверная информация. Про меню и тулбары я могу сказать совершенно точно просто потому, что был одним из тех людей, кто их делал :) там действительно весьма монструозные хаки в шаблонах (чтобы обеспечить поведение, максимально эквивалентное старым «офисным» коммандбарам в VS 2008), но все же это Menu и MenuItem. Комбо-боксы на тулбарах — это тоже ComboBox (точнее, отнаследованный от него класс с кастомизацией).
Причем больше всего кастомизации именно в тулбарах и меню. В диалогах (напр. «Customize Toolbar») практически все контролы — самые обычные.
WPF как раз наглядный пример оверинжиниринга — там очень много всего под капотом для того, чтобы стандартные средства были настолько гибкими, что покрывали даже самые безумные сценарии (ну, например, если вам нужен текстбокс внутри нажимабельной кнопки, это делается в две строчки). Плюс к этому очень много extensibility везде. Так что как раз на полноразмерных примерах он раскрывается в полную силу.
Грустно, что Silverlight и Windows XAML далеко не такие гибкие, несмотря на внешнее сходство.
>> там только XAML parser и core используется, а все контролы и окна свои.
В случае VS это не так. Там свои тулбары и меню (хотя и то не с нуля, а сильно кастомизованные — штатными средствами, через наследовение и шаблоны — стандартные контролы). Потом tool windows (рамка), и все, что связано с их докингом. Редактор, разумеется.
Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема (которую может легко подключить себе любое расширение).
Это старый холивор. «Ближе-дальше» — это, разумеется, чисто субъективно. На самом деле проблема в том, что мы половину слов с th заимствовали из греческого с «ф», а другую половину — через латынь с «т». Что вам больше режет слух: «феатр», «феорема», «фесей» и «мафематика», или «теодор», «атена», «аритметика» и «этер»?
Ну и, что характерно, соответствующую греческую букву мы сегодня таки называем «тетой», а не «фитой».
И, да, эксплорер запоминает последний размер окна.
Впрочем, в Голливуде муляжи АК не должны залежаться в любом случае.
Ну и плюс отдельные штаты могут запретить это на свой территории, разумеется.
Имхо все же в fire and forget, последний должен быть явным, а не по умолчанию.
Но сам по себе дизайн с f'n'f вполне нормален.
Но любая другая стратегия — это отодвигание решения проблемы на потом. Причем, чем дольше отодвигают, тем сложнее будет решать (потому что больше сломается).
После продолжительного хождения по граблям, кстати, решили, что мы не будем поддерживать 4.0 :) тем не менее, в процессе появилась пачка вспомогательных методов для того, чтобы явно управлять поведением тасков в ситуациях без await. Может, кому еще пригодится.
Не совсем. Использовать WPF можно было и до того — например, все связанное с WPF-дизайнером в VS 2008 уже было на WPF. Переписывание шелла и редактора было связано скорее с желанием уйти от старого и трудноподдерживаемого Win32-кода, ну и заодно получить профит в виде themability, поддержки high-DPI, и тому подобных штук. Для авторов расширений это упростило некоторые вещи за счет того, например, что главный message pump в VS стал понимать некоторые WPF-специфичные вещи, но это было не столь принципиально.
При этом в VS осталось полно кода на Win32 и WinForms — задачу переписать все разом никто не ставил. Вот картинка с состоянием дел на момент релиза VS 2010:
Сейчас WPF стало больше, а остального — меньше (напр., Solution Explorer уже два релиза как WPF, опять же новый UI для тестов...). Плюс появились куски на HTML5. Хотя HTML там в принципе был и раньше — если кто задавался вопросом, почему визарды для C++-проектов позволяют выделять произвольный текст в диалоге мышкой, то вот как раз поэтому.
>> Но на сколько я знаю в Visual Studio Core (хз как эта команда сейчас называется) даже ComboBox нигде не использовали из WPF.
И тогда, и сейчас — VS Platform, в котором несколько команд, на самом деле. Редактор на WPF переводила его же команда, а всем остальным заведовал VS Platform Shell team.
Насчет остального же у вас неверная информация. Про меню и тулбары я могу сказать совершенно точно просто потому, что был одним из тех людей, кто их делал :) там действительно весьма монструозные хаки в шаблонах (чтобы обеспечить поведение, максимально эквивалентное старым «офисным» коммандбарам в VS 2008), но все же это Menu и MenuItem. Комбо-боксы на тулбарах — это тоже ComboBox (точнее, отнаследованный от него класс с кастомизацией).
Причем больше всего кастомизации именно в тулбарах и меню. В диалогах (напр. «Customize Toolbar») практически все контролы — самые обычные.
Грустно, что Silverlight и Windows XAML далеко не такие гибкие, несмотря на внешнее сходство.
В случае VS это не так. Там свои тулбары и меню (хотя и то не с нуля, а сильно кастомизованные — штатными средствами, через наследовение и шаблоны — стандартные контролы). Потом tool windows (рамка), и все, что связано с их докингом. Редактор, разумеется.
Но всякие там текстбоксы и прочие стандартные контролы — родные WPF, просто своя тема (которую может легко подключить себе любое расширение).
Ну и, что характерно, соответствующую греческую букву мы сегодня таки называем «тетой», а не «фитой».
И Tcl — «ти-си-эль» или «тикль».
Другой вопрос, что его зачем-то изувечили в «ф», хотя «т» было бы куда ближе.