Это и так скриптовый язык
Моя недавняя статья про возможность рассмотрения того, что, быть может, когда-нибудь мы добавим «верхнеуровневые» методы в C# для облегчения «скриптовых» сценариев породила неожиданное количество немедленных выражений отвращения. Почитайте комментарии, чтобы понять, что я имею в виду.
Две вещи сразу приходят на ум.
Прежде всего, предложение исходящее от значительного числа комментаторов: «вместо разрешения на размещение методов на верхнем уровне, усильте директиву using». То есть, если вы бы написали «using System.Math;», то все статические члены этого класса можно было использовать без уточнения.
Хотя это весьма разумная идея, которую часто просят реализовать, она на самом деле не относится к проблеме, которую решают свободные методы. Улучшенный «using» облегчает разработчику написание вызова. Смысл свободных методов для скриптовых сценариев – в облегчении разработчику написания декларации. Смысл – в устранении «ритуала» объявления лишнего класса только для использования в качестве контейнера для кода.
Во-вторых, и в общем, я удивлён этой негативной реакцией потому, что C# уже и так скриптовый язык, и поддерживает это почти десять лет. Не выглядит ли знакомо этот фрагмент кода?
<%@ Page Language="C#" %>
<script runat="server">
void Page_Load(object sender, EventArgs e)
{
// всякое
}
</script>...
А где же класс? Где директивы using, которые позволяют использовать EventArgs без уточнения? Где код, который подписывает этот метод на событие? Весь ритуал, похоже, каким-то образом устранён. Это явно выглядит для меня как «метод верхнего уровня».
Конечно мы знаем, что всё это не так где-то за кулисами. ASP.NET выполняет текстовые трансформации над страницей для генерации файла с классом. И, конечно, мы рекомендуем вам использовать технику «выделенного кода» для создания файла, который содержит методы в контексте явного (частичного) класса страницы, чтобы подчеркнуть, что этот подход к обработке серверной логики основан на классах.
Но вы определённо не обязаны использовать «выделенный код». Если вы традиционалист ASP (как я!) и предпочли бы скорее рассматривать C# как «скриптовый язык», который «скриптует» создание контента на веб сервере, то так и пишите. Вы можете просто помещать ваши «свободные методы» в блоках «script», а «свободные выражения» в блоках «<%%>», и вы избежите ритуала явного объявления контейнеров для этих элементов кода. Код ASP.NET автоматически реорганизует ваш «скриптовый» код в то, с чем может работать компилятор C#, добавляя весь скучный код стандартной «рыбы», который нужен только для того, чтобы порадовать компилятор.
Но теперь задумайтесь о нагрузке, которая ложится на разработчиков ASP.NET благодаря такому дизайну языка. Эти парни не могут просто выделить код C# и отдать компилятору C#. Они вынуждены иметь глубокое понимание разрёшенных топологий контейнеров кода, и выполнять приседания – не слишком сложные приседания, но всё же приседания – для генерации класса, который можно реально скомпилировать и исполнить.
Такая же обязанность ложится на каждого разработчика, который бы хотел предоставить возможность исполнения пользовательского кода в своём приложении, будь то в виде расширяемости через скриптинг, или разрешая вычисление пользовательских выражений (например, запросов). Это обязанность, вменённая разработчикам вспомогательных инструментов, таких, как «snippet compiler» Джона Скита, или LINQPad. Это обязанность разработчиков, которые хотят поэкспериментировать с REPL-подобными подходами к быстрой разработке прототипов, тестов, и так далее.
Я не испытываю чрезмерного восторга от удобства возможности сэкономить пять символов, устраняя «Math.» при попытке вычислить косинус. Привлекательные ценности – в том, что мы можем снизить стоимость разработки инструментов, которые привносят мощность языка C # в сторонние приложения, и в то же время сделать возможными новые способы быстро экспериментировать и разрабатывать высококачественный код.
Конечно же, мы не хотим этим разрушить существующие ценные достижения языка; как я и сказал в прошлый раз, мы также верим в то, что есть большая польза в таком дизайне языка, который естественно подталкивает профессиональных разработчиков крупномасштабных приложений к построению хорошо структурированных программ на основе компонентов.
Как во всех проектных решениях, столкнувшись с набором конкурирующих, привлекательных, ценных, и несовместимых идей, мы вынуждены искать рабочий компромисс. Мы не знаем способа для этого, кроме как рассмотрения всех возможностей, что мы и делаем в данном случае.