А, понятно. Но с лямбдами, во-первых, вы платите за оверхед, во-первых, создания делегата, а во-вторых, виртуального вызова через него (насколько мне известно, JIT не умеет это оптимизировать). Ну и вам придется расписывать полностью все типы в сигнатуре. Т.е. по сравнению с приватным методом, вы выигрываете только более ограниченную область видимости, но за счет производительности. Если вам нужен Math больше, чем пару раз, то, скорее всего, производительность важна :)
Идеальным было бы, если бы using можно было писать внутри классов и методов…
Там есть еще отличия. Из очевидного — в IDE, если у вас включен break on exceptions, то с паттерном catch-throw это будет расцениваться, как новый эксепшн, со всеми вытекающими. С фильтром — нет.
Из неочевидного — фильтры выполняются на первом проходе по стеку, когда определяется, в какой catch-блок перейти — и до отмотки стека. Т.е. всякие там finally и using от точки выброса до фильтра еще не отработали. Иногда это бывает полезно (а иногда — это очень хорошо запрятанные грабли).
Что вы имеете в виду под «локальными функциями», несколько непонятно. Вложенных методов в C# нет, так что максимум, что вы можете сделать, это написать метод-обертку на вашем классе. Но зачем, если using System.Math сделает то же самое в несколько раз короче? Ваш код от этого понятнее не станет.
Методом текущего — да. Но он может оказаться методом объекта, доступного из текущего через свойство Console.
В общем случае, вам все равно придется посмотреть, откуда оно. Что, впрочем, в любой нормальной IDE делается одним нажатием (или одним движением мышой).
А в конкретном случае, если вы видите WriteLine или там Abs, я не думаю, что у вас реально возникнет такой вопрос.
Это понятно. Вопрос (к автору оригинального комментария) был о другом — что плохого в расширении функционала using до импорта членов классов? Чем классы хуже неймспейсов в этом смысле, с его т.з.
Я думаю, «проблема» тут скорее в том, что люди интуитивно преполагают, что объектов там столько же, сколько и литералов. Т.е. внезапным оказывается не то, что NSString можно изменять через хитрые касты, а то, что при этом изменяется какой-то «другой» NSString (который на самом деле тот же самый). То есть «проблемой» является именно алиасинг, а не нарушение иммутабельности.
Вы так толком и не объяснили, почему именно. До C# 6 using работал точно так же, но был ограничен пространствами имен (т.е. можно было импортировать имена типов из неймспейса, но не имена методов из класса). Теперь он работает и с классами тоже. В чем принципиальная разница?
Или вы, когда пишете код на C#, всегда пишете System.Collections.Generic.List<System.String>?
Это не with, потому как область видимости всегда — файл целиком, и импортировать так можно только члены статических классов (которые, по сути, являются модулями).
Не используйте Python 2.7.3 — в нем бажный OpenSSL (пусть здесь это не используется, но если вы его поставите, то потом, скорее всего, будете использовать и для других вещей, для которых нужен питон).
Да, в любой технологии есть грабли. Но их количество сильно разнится, равно как и шанс их там найти в повседневных вещах. И это, на мой взгляд, как раз очень важный критерий.
Насчет большей части тоже не соглашусь — я как раз имел в виду именно язык (откуда и взял примеры). Еще навскидку — область видимости «this», например. Или вариации на тему того, что будет результатом []+[], []+{} и {}+[] (если вы не видели соответствующую презентацию — попробуйте).
И подход «преподавать подмножество» тут не очень хорошо работает. Ну ок, вы не покажете им ==, но плюс-то нужен будет для сложения, например. Или переменные — как только вы их вводите, появляется вопрос с областью видимости.
И вот как раз на тему объяснения, почему такие вещи работают таким образом, в JS очень часто нет внятного ответа. Точнее, он есть, но звучит так: «потому что, когда Brendan Eich писал первую реализацию языка на коленке за две недели, у него получилось так, а дальше осталось для совместимости».
Питон (особенно третий) в этом смысле намного более логичен, и там не нужно аккуратно танцевать вокруг грабель. Наиболее простой способ что-то сделать, как правило, является и наиболее очевидным, и правильным.
JS в качестве первого языка плох тем, что там очень много вещей неочевидных и не имеющих логического объяснения, причем в самых элементарных вещах вроде == и ===, или области видимости переменных. И учить придется с оглядкой вот на это все, чтобы никто случайно не наступил на грабли (или, что еще хуже, не научился наступать на них целенаправленно ради какого-то полезного побочного эффекта).
Если вам известно, как собрать такой тип, который работает с полноценной верификацией — это уже дыра в песочнице. Вы бы тогда сначала лучше отписались сначала на secure@microsoft.com…
Идеальным было бы, если бы using можно было писать внутри классов и методов…
Из неочевидного — фильтры выполняются на первом проходе по стеку, когда определяется, в какой catch-блок перейти — и до отмотки стека. Т.е. всякие там finally и using от точки выброса до фильтра еще не отработали. Иногда это бывает полезно (а иногда — это очень хорошо запрятанные грабли).
И я не думаю, что это будет сложнее дебажить, чем винегрет из строковых литералов и плюсов.
Т.е. фича несколько спорная, но хуже она точно не сделает…
Там нужны были инициализаторы, а их не было.
Что вы имеете в виду под «локальными функциями», несколько непонятно. Вложенных методов в C# нет, так что максимум, что вы можете сделать, это написать метод-обертку на вашем классе. Но зачем, если using System.Math сделает то же самое в несколько раз короче? Ваш код от этого понятнее не станет.
В общем случае, вам все равно придется посмотреть, откуда оно. Что, впрочем, в любой нормальной IDE делается одним нажатием (или одним движением мышой).
А в конкретном случае, если вы видите WriteLine или там Abs, я не думаю, что у вас реально возникнет такой вопрос.
Или вы, когда пишете код на C#, всегда пишете System.Collections.Generic.List<System.String>?
Возможность такая была давно — new Dictionary { { «key», «value» },… }. Добавили новый синтаксис, который мапится на индексер вместо Add.
Текущей версией для ветки 2.7 является 2.7.9.
Ну и пункт про вырабатывание вредных привычек остается в силе.
Насчет большей части тоже не соглашусь — я как раз имел в виду именно язык (откуда и взял примеры). Еще навскидку — область видимости «this», например. Или вариации на тему того, что будет результатом []+[], []+{} и {}+[] (если вы не видели соответствующую презентацию — попробуйте).
И подход «преподавать подмножество» тут не очень хорошо работает. Ну ок, вы не покажете им ==, но плюс-то нужен будет для сложения, например. Или переменные — как только вы их вводите, появляется вопрос с областью видимости.
И вот как раз на тему объяснения, почему такие вещи работают таким образом, в JS очень часто нет внятного ответа. Точнее, он есть, но звучит так: «потому что, когда Brendan Eich писал первую реализацию языка на коленке за две недели, у него получилось так, а дальше осталось для совместимости».
Питон (особенно третий) в этом смысле намного более логичен, и там не нужно аккуратно танцевать вокруг грабель. Наиболее простой способ что-то сделать, как правило, является и наиболее очевидным, и правильным.