Критические изменения и именованные аргументы
Прежде чем переходить к теме сегодняшнего поста, я хочу поблагодарить всех, кто прислал свои замечания о Roslyn CTP. Пожалуйста, продолжайте в том же духе. Я обязательно напишу несколько статей о Roslyn в ближайшее время, но последние несколько недель у меня не было на это времени, поскольку я был слишком занят непосредственно реализацией.
В C# 4.0 мы добавили «необязательные и именованные параметры»; возможность эта заключается в том, что вы можете опустить некоторые параметры при вызове метода, и указать некоторые из них по имени. Это способствует самодокументированию кода; кроме того, это упрощает работу со старыми объектными моделями, которые содержат множество параметров, при этом только немногие из них являются существенными. По поводу «именованной» части этой возможности я неоднократно слышал комментарий, что она вносит критические изменения. Обычно такой комментарий выглядит следующим образом:
Предположим, вы разрабатываете библиотеку, которой будут пользоваться другие разработчики. И, конечно же, если вы меняете детали публичного интерфейса библиотеки, то можете сломать код пользователей этой библиотеки. Например, при добавлении в класс нового метода существующий код может перестать компилироваться из-за неоднозначности вызова старого метода. В прошлом, изменение имени формального параметра не было «критическим изменением», поскольку пользователи всегда передавали параметры согласно их позиции. Перекомпиляция кода никогда не приводила к другим результатам. В мире с именованными параметрами, изменение имени параметра может привести к поломке работающего кода.
Хотя такой комментарий понятен и поучителен, все же он не совсем точен. Не точен вывод, что подобные критические изменения являются чем-то новыми; на самом деле, изменения только имен формальных параметров в библиотечном коде всегда ломали код. Visual Basic всегда поддерживал вызов методов с именованными параметрами. В прошлом, изменение имени формального параметра было критическим для всех, кто применял Visual Basic, а это, потенциально, большое число пользователей. Теперь такие изменения стали потенциально критическими для еще большего числа пользователей. Добавление новой возможности в язык C# не изменило того, что подобный риск существовал всегда!
Разработчики библиотек уже должны были обращать внимание на изменения имен формальных параметров, и они должны продолжать быть внимательными на этот счет и теперь.