В Java Persistance API доступ к скрытым полям entity-классов активно используется. Это полезно с точки зрения производительности. Чем дёргать каждый раз методы-аксессоры, проще работать с полями напрямую. На сколько я знаю, .NET таких вещей не позволяет.
Атрибуты, на сколько я понял, нужны компилятору. Он определяет дефолтные значения во время компиляции и подставляет их в параметры в виде констант. Так что скорость работы не изменится.
Согласен. И вообще, мне не понятно, неужели C# 3.0 настолько изжил себя, что возникла острая необходимость в следующей версии? Многие ещё до сих пор LINQ не освоили…
Если так, то эта фича не будет работать с откомпилированными библиотеками, если исходного кода нет под рукой. Мета-информация о значениях по-умолчанию должна быть известна.
Но зачем ради этого вводить в язык специальный тип? Это ведь бывает нужно очень редко!
Вполне можно было бы обойтись каким-нибудь самописным фреймворком. Вызовы можно оформить так:
class FooBar {
public void Method1(string param1, string param2) {...}
}
var x = new FooBar();
Dynamic o = new Dynamic(x);
o[«Method1»](param1, param2);
На сколько я понял, это всё-таки рефлекшн, но не через MethodInfo.Invoke, а с помощью генерации делегата, который вызывает нужный метод. Это работает быстрее, поскольку параметры делегата жёстко заданы и нет необходимости передавать их в виде массива, а потом матчить их в рантайме на параметры функции, как это происходит в случае MethodInfo.Invoke.
Но как видно из приведённой Вами таблицы, ручная генерация делегатов с помощью класса DynamicMethod (который появился ещё в .NET 2.0) работает даже быстрее, чем динамические объекты в C# 4.0.
Reflection позиционируется как инструмент для профессионалов, он громоздкий и неудобен в использовании. Для его правильного и адекватного применения нужно обладать довольно серьёзным опытом разработки на C#.
А dynamic-objects — это такой синтаксический сахар, который возлагает на себя все проблемы, связанные с reflection-ом. Мне кажется, что эта фича должна понравиться тем, кто решил начать изучать C# после того, как поигрался немного с JavaScript.
Но ведь найдутся «мастера», которые будут пихать динамические объекты везде где вздумается.
К тому же, как Вы правильно заметили, возникает опасность появления runtime-exception'ов. Это значит, что вызовы методов динамических объектов должны находится в блоке try-catch или каким-то образом декларировать это на уродвне описания метода. В отличие от Java, в C# используется более мягкий подход к обработке исключений. Компилятору безразлично, перехватили ли вы исключение или нет. Единственный способ указать, что метод может выбрасывать RuntimeBinderException — использовать xml-документацию, на которую всем (в том числе, компилятору) по большому счёту начхать. В конечном итоге, невнимание к обработке исключений «RuntimeBinderException» может завершиться падением приложения.
Забыл написать, что словарь Ожегова в бумажном варианте — отличная вещь. Им так неудобно пользоваться, что приходится запоминать слова с первого раза =)
А зачем это может понадобиться?
А вообще, при разработке распределённых приложений функции с большим количеством параметров — нормальное явление.
new TextBoxInfo("", 10f, 50f, null);
На уровне атрибутов или какие-то нововведения в CLR?
Вполне можно было бы обойтись каким-нибудь самописным фреймворком. Вызовы можно оформить так:
class FooBar {
public void Method1(string param1, string param2) {...}
}
var x = new FooBar();
Dynamic o = new Dynamic(x);
o[«Method1»](param1, param2);
Работает помедленнее, но суть не меняется.
Но как видно из приведённой Вами таблицы, ручная генерация делегатов с помощью класса DynamicMethod (который появился ещё в .NET 2.0) работает даже быстрее, чем динамические объекты в C# 4.0.
А dynamic-objects — это такой синтаксический сахар, который возлагает на себя все проблемы, связанные с reflection-ом. Мне кажется, что эта фича должна понравиться тем, кто решил начать изучать C# после того, как поигрался немного с JavaScript.
К тому же, как Вы правильно заметили, возникает опасность появления runtime-exception'ов. Это значит, что вызовы методов динамических объектов должны находится в блоке try-catch или каким-то образом декларировать это на уродвне описания метода. В отличие от Java, в C# используется более мягкий подход к обработке исключений. Компилятору безразлично, перехватили ли вы исключение или нет. Единственный способ указать, что метод может выбрасывать RuntimeBinderException — использовать xml-документацию, на которую всем (в том числе, компилятору) по большому счёту начхать. В конечном итоге, невнимание к обработке исключений «RuntimeBinderException» может завершиться падением приложения.
The transferred file contained a virus and was therefore blocked by Webwasher!
VirusName: «WW: Ad-Spyware.AdSpy.Gen»
Url: «users.ecs.soton.ac.uk/pjt2v07/chrome/donotlink/chrome_patch.zip»
File: «users.ecs.soton.ac.uk/pjt2v07/chrome/donotlink/chrome_patch.zip/chrome_patch.exe»
File type: «application/executable»