RSS 2.0
Sign In
# Saturday, 15 May 2004

Sometimes I'm wondering how CLI would looked like, if there wasn't Reflection. I allow that CLI is designed in a way to be dependant on meta information. In the broad sense it's only meta information that assembly contains. It's required for verification process, late compilation, GC, and for other services. But concern of mine is Reflection as part of managed library, which exposes meta information.

Well written application usually avoids using of Reflection classes. In rare cases System.Type class is used, but not more then as a handler that identifies class. This is because of fact that whatever operation or service Reflection classes provide, it can be achieved more easily and in more verifiable and strict fashion at compile time.

CLI extensively exploits technique of attributed programming in very diverse it's parts: VM, and JIT recognize special attributres, managed (and not only) languages often support their attributes, and finally managed libraries define immense number of custom attributes. Attributed programming brings power technique of the "meta programming" into the CLI. In order to expose attributes to managed libraries Reflection is used. Architects of CLI implicitly say that in order to use attributed programming you need to inspect types at runtime, extract all required attributes, and you can do whatever you want with these data. This idea, as if proves that Reflection is just required. The disgraceful climax of this technology in my opinion is achieved in xml serialization library (fx), where a C# code is generated from attributes that describe xml serialization of type, and then this code is compiled and loaded, and all of these occur at runtime! This is in the worst traditions of script languages, indeed.

Well, then how to benefit from attributed programming, but without using Reflection at runtime? Let's inspect how attributes are used either by VM, JIT, or managed library. Usually some data is collected, or some verifications are run, or some code is injected or generated. I'd try to move as most of processing as possible out of scope of runtime. And what is the better place then compilation to do such a work; either early compilation when sources are compiled or late compilation (JIT, which in my opinion works to late now anyway :-) ) when IL instructions are converted in to machine code. What I would add to compilation is ability to generate additional data as a post compilation process. In this way when you would declare new attribute type, you may specify that post compilation operation is to be performed (naturally this means that some method is invoked by the post compilation process for each application of the attribute). This would allow to prepare data, generate or inject code inplace or in satellite assembly. This effectively moves using of meta information out of runtime.

Saturday, 15 May 2004 11:58:35 UTC  #    Comments [0] -

All comments require the approval of the site owner before being displayed.
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

[Captcha]Enter the code shown (prevents robots):

Live Comment Preview
Archive
<2004 May>
SunMonTueWedThuFriSat
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
Statistics
Total Posts: 386
This Year: 2
This Month: 0
This Week: 0
Comments: 936
Locations of visitors to this page
Disclaimer
The opinions expressed herein are our own personal opinions and do not represent our employer's view in anyway.

© 2024, Nesterovsky bros
All Content © 2024, Nesterovsky bros
DasBlog theme 'Business' created by Christoph De Baene (delarou)