Introducing ActiveSupport.NET

To my surprise, none of my googling seemed to come up with anyone doing this.  So I figured I’d start it off (please let me know if you know of any other efforts already underway).  As some would say, taking extension method abuse to a whole new level.  :D   But, I see these little utility methods to be a good fit as extensions methods to make the syntactic sugar that much sweeter.

One of the many great things about working in Rails is the core extensions in the ActiveSupport library.  It just *becomes* part of the Ruby language as you work with Rails.  And I wanted to get that same feeling when working in C#.  So this is my attempt to start porting over the core extensions from Ruby’s ActiveSupport Library.

So far I’ve just ported over a few string access and conversion extensions, but check ‘em out and let me know if you’d find something like this to be useful.  Here are some examples of what’s currently supported…

 1: // some accessors
 2: "blah".At(2) // 'a'
 3: "blah".First() // 'b'
 4: "blah".First(2) // "bl"
 5: "blah".From(1) // "lah"
 6: "blah".Last() // 'h'
 7: "blah".Last(2) // "ah"
 8: "blah".To(2) // "bla"
 9:  
 10: // couple simple conversions (still needs lots of work)
 11: "1/4/2008".ToDate() // DateTime
 12: "01:15:35".ToTime() // DateTime

You can grab the source at its google code repository.  You can just do a “build test” from a command line in the trunk to run the unit test suite.

Enjoy.  :-)

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in c#, rails, ruby. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

3 Responses to Introducing ActiveSupport.NET

  1. You’ve added language extensions, for example, for conversion. It just so happens that you got an implementation for System.String, but namespaces for extension libraries should be named for what they communicate when used in a “using” statement since it’s that statement that documents the concern being added to the language.

    Namespace naming rules for extension libraries shouldn’t follow namespace naming rules for class libraries. The “using” statement takes on a whole new meaning when used to extend the language, and so those namespaces that are imported should be reflective of the kind of concern and functional ability that we’re bringing into play.

    Your basic choice for a root namespace should be the root concept that users will identify, being “ActiveSupport”. If you use no other namespace for these extension libraries, “ActiveSupport” should be the bare minimum. You may choose to offer finer-grained differentiation if needed or wanted: ActiveSupport.Access, ActiveSupport.Conversion, etc.

    You might try experimenting with thinking of namespaces for extension libraries at *language extensions* rather than *type extensions* when possible.

  2. joeyDotNet says:

    Cool, thanks a bunch for the input Scott. I’m definitely still trying to figure out the best way to structure things to make it as simple as possible to use. And this really helps.

  3. Cool idea, and Scott’s comment was useful too.