Comments by Kelqualyn

Kelqualyn 1-Nov-11 2:44am View

Deleted

An exception thrown inside Singletin's .ctor will be thrown on type initialization (instead of first access to Instance property and even if you will never use it) and wrapped into TypeInitializationException. Alternative 6 solves that without any performance loss.

Kelqualyn 6-Sep-11 0:33am View

Deleted

Reason for my vote of 5
It hard to track down.
IDisposable and using statement us MUST HAVE for unmanaged classes, used from managed code.

Kelqualyn 23-Aug-11 4:34am View

Deleted

Reason for my vote of 4
Interesting, but too slow.
Slow methods are:
GetProperties()
GetCustomAttributes()
SetValue()
Can be rewritten using LCG API (or LINQ.Expressions) and delegate cache.

Kelqualyn 5-Aug-11 2:57am View

Deleted

Look at next post :-)

Kelqualyn 4-Aug-11 15:56pm View

Deleted

Try to convert step-by-step instead of direct conversion.
Every enum is derived from simple numeric type. Default is System.Int32, but you can specify other (e.g. SByte) in enum declaration.
If you want to convert something to enum type, convert it to that enum's base type. And only than convert value to enum type.
Also, you don't need to construct IfThenElse expression. You can just make different expression for enum type. (If condition can be evaluated at expression construction time, use it.)

Kelqualyn 2-Aug-11 3:00am View

Deleted

Reason for my vote of 2
New poperty is not virtual.
It uses direct field access instead of .base calls.

Kelqualyn 26-Jul-11 6:17am View

Deleted

Core problem in "var" declarations is inability of someone who reads code to suppose type of variable.
If you cant suppose what exact type "GetData()" returns, it shows only one thing - you don't know what exactly this method does. If you don'know, don'even read next line until you will read code of "GetData()" or its specification. Any modification of code after "var" declaration is prohobited for you, until you will know.
Var declarations forces programers to inspect and understand code's invienronment and dependencies clearly before they will made changes.

Yes, it takes much time, but it is good.
Lasy programmer is not the one, who don't exactly specifies variable's type. Lasy programmer is the one, who tries to modify code without understanding of specifications and purpose of used methods.

Correct method naming is only one thing, that can help us to understand.
In most cases "how result was constructed" is more important knowledge then "what type of data does this method returns" and includes it.

Kelqualyn 20-Jul-11 3:45am View

Deleted

Yep.
Using CodeDom compiler for such task probably will result huge amount of loaded assemblies.
The best way is probably emitting IL using Reflection.Emit namespace and DynamicMethod class (part of LCG API, introduced in .NET Framework 2.0).

Kelqualyn 15-Jul-11 12:26pm View

Deleted

To compile this code you need to target .NET Framework 4.
Building a map is only one thing, making this code faster. Second one - is runtime compiled property-accessing delegates. This delegates are much faster then PropertyInfo.SetValue method. It takes some time to compile them, but once done, result is stored inside DataAccessExtensionReflectedType._setters static field. After first access (when delegate-compiling process finishes), there is no calls to Reflection API done at all while executing SetPropertiesFrom method.
Note that Type.GetProperties, and PropertyInfo.SetValue are slow, as most of Reflection API.
With some alter, code can be adopted to compile under .NET Framework 2.0. (Replace Expression API to Reflection.Emit LCG)
Additionally I will improve my alternate, to met your exact specification (as you see, I missed "value is DBNull" check).

Kelqualyn 15-Jul-11 2:48am View

Deleted

deleted

Kelqualyn 23-Jun-11 14:44pm View

Deleted

Reason for my vote of 3
Such reflection is much slower then handwritten code. Reflective code can be rewritten to be as fast as handwritten one.

Comments by Kelqualyn (Top 11 by date)