On a Simple IronPython Dependency Injection Framework
Continuing with my “IronPython will end world hunger series,” I’m again shamelessly self/cross-promoting a Code Voyeur article that I think it’s worth a read.
A Simple IronPython Dependency Injection Framework
It’s not Spring.NET and it’s not Windsor, but I really like the idea of configuring objects with IronPython rather than XML.
Enjoy!
On a Simple IronPython Validation Framework
I do try to keep the content between Code Voyeur and dll Hell distinct. OK, there’s not much content on either… But I think my latest (up to 4!, that’s 4 not 4 factorial) article on Code Voyeur is a pretty neat idea. Shameless cross-promotion link below:
A Simple IronPython Business Object Validation Framework
On Cookies and Data Binding with SmartDispatcherController
MonoRail’s SmartDispatcherController will automatically bind controller method parameters to request parameters. So the arg0 and arg1 parameters in the method below -
public void DoSomething(string arg0, int arg1)
{
...
}
will have the values castle and 5 respectively when the request is constructed like
/SomeController/DoSomething.rails?arg0=castle&arg1=5.
While this is certainly a useful feature, it’s important to remember that any item in the Request.Params collection is a candidate for binding. At work, my team and I recently ran into a problem where this behavior resulted in some unexpected exceptions.
The site running MonoRail has some classic ASP that’s being phased out, but is still accessed during a visitor’s session. During the ASP flow, some session cookies are set. One of these cookies happens to share the name of a parameter in one of our controller methods. When this controller action was hit, the values from the query string param and the session cookie were both used during parameter binding.
Our logs showed that the requests were coming in correctly and we couldn’t reproduce the exception by recreating the request. Fortunately we had a dump of the request param values that were throwing the exceptions. We noticed the same param key was set in both ASP and MonoRail handled requests. This observation led one of my developers to speculate about cookie binding. A quick look at the Castle sources confirmed that suspicion. After a quick parameter name change, the exceptions stopped.
On an Alternative to the var Keyword in C#
I recently attending a meeting of the Fairfield / Westchester .NET User Group, in which Richard Hale Shaw presented on LINQ and C# 3.5 features. During the presentation there was a brief but spirited debate over the use of the var keyword in C#. Specifically, at issue was using var without anonymous types.
Richard, who gave an excellent presentation, took the “for” side. He argued in favor of the more terse variable declaration syntax provided by var. On this point I agree. If the compiler is able to infer the declared type from its assignment (new or method return type), then why not save some keystrokes by replacing the former with the latter?
KeyValuePair<string, string> items = new KeyValuePair<string, string>();
var items = new KeyValuePair<string, string>();
The “against” crowd objected to the dynamic feel of the var keyword. It was argued that code clarity is sacrificed for this lack of verbosity. It’s easy to know the type of items in the first line of code above. The second line is still pretty clear. But there’s another case…
var items = someObject.SomeMethodReturningAKeyValuePair();
If a developer isn’t familiar with the return type of SomeMethodReturningAKeyValuePair, then Visual Studio has to provide this information (mouse over, Intellisense). Personally, I think spending time with any language that supports duck typing gets one over this concern rather quickly…
Personally, I would prefer there not be a var keyword. Don’t get me wrong, I’m a fan of anonymous types. It’s just that var seems unnecessary. As an alternative approach consider Python and Boo.
Python is a scripting language and as such is not statically typed. It clearly makes sense for Python not to require a declaring type. But Boo, which is statically typed, will compile the code below just as easily as Python will interpret it.
d = Duck()
Neither Boo nor Python require those three contentious characters, OK four counting the space. So why does C#? If it’s a matter of scope, Python has a solution:
a = "foobar"
def foo():
a = "bar"
def bar():
global a
a = "foo"
print a
foo()
print a
bar()
print a
The snippet above will print the lines below. The global keyword is used to tell the interpreter that a global variable is being changed. Without it, Python will create a new locally scoped variable.
foobar
foobar
foo
I’ve finally begun my long overdue introduction to LINQ. It’s too early for me to comment in any meaningful way on LINQ as an enhancement to C#. But I will discuss what I think is an interesting trend in C#’s evolution as a language - syntax enhancements for BCL types.
I admit this is a strange thing with which to concern myself. C# and the BCL have always had a reciprocal relationship. The common type system helps to tie language and library together by way of int, string and the like. I certainly have never found it odd that C# gives special language support to strings, even though the String class is just another type in System. But when C# introduced the ? to turn an int into a Nullable
The using keyword is another example. IDisposable is a language dependency. A foreach loop binds System.Collections to the language specification. LINQ takes these macro-like language enhancements to a new level. Now a query language is baked right into the language itself. LINQ’s language features are just syntactic sugar on top of the LINQ API. Additions such as extension methods, properties and anonymous types might also be considered compiler candy, but these features feel more local to the language.
It looks like C# as a language will continue to evolve by adding both novel features and API-wrappers. As this coupling continues, it will be interesting to see what constraints are placed on the language. Could C# with all of its BCL macros ever effectively be ported to run on the JVM? Will the C# language itself one day become extensible to allow direct support for DSLs or commonly used APIs? Will the language have to devolve to remove features that apply to only defunct APIs?