ActiveSupport.NET – Namespace Overhaul

Figured I’d try and get this nailed down as early as possible.  So after some recent feedback, I decided to change the namespacing so that it focused more on “behavior/concern” rather than “types”.  What this means is…

Instead of:

  • using ActiveSupport.Core.Extensions.String;  // containing string extensions for access, conversions, etc.
  • using ActiveSupport.Core.Extensions.Integer;  // containing integer extensions for access, inflections, etc.

It’s now just this:

  • using ActiveSupport;  // just basic extensions
  • using ActiveSupport.Access // all accessor-based extensions for ALL types
  • using ActiveSupport.Conversions // all conversion-based extensions for ALL types

I’m pretty much thinking the accessor based stuff will probably get used the most.  But either way, by grouping this way, I’m hoping they’ll be a bit easier use.  And of course when our R# 4.0 EAP shows up next (right Ilya? :) all of this namespace’ry will must magically work for us.  :)

What do you think?  Is this a better approach to keeping things clean and organized?

Related Articles:

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

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

2 Responses to ActiveSupport.NET – Namespace Overhaul

  1. Chad Myers says:

    The only thing with that is that if you ever add anything else to ActiveSupport beyond extensions, you will run into problems with the namespaces again.

    How ’bout:

    using ActiveSupport.Ext;
    using ActiveSupport.Ext.Access;
    using ActiveSupport.Ext.Conversions;

    Better yet, if you have things like: Date/Time concerns (that involve System.DateTime, System.Int32, System.String):

    using ActiveSupport.Ext.DateAndTime;

    String Canonical concerns (which may involve ext methods on System.String, System.Int32, System.DateTime, etc)?

    using ActiveSupport.Ext.StringCanonical;

  2. joeyDotNet says:

    Yeah, I guess my vision for AS.NET is actually to keep it pretty small and focused on simply language extensions. Looking at the current ActiveSupport library for Ruby, the vast majority of features is in their “CoreExtensions” namespace. There are a couple other things like some JSON utils, which may or may not make it into AS.NET, but we’ll see… :)

    What would you like to see included in AS.NET besides the language extensions?