Comments on: Introducing ActiveSupport.NET http://lostechies.com/joeybeninghove/2008/02/07/introducing-activesupport-net/ Just another LosTechies site Fri, 15 Oct 2010 23:08:45 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Christopher Bennage http://lostechies.com/joeybeninghove/2008/02/07/introducing-activesupport-net/#comment-90 Christopher Bennage Fri, 08 Feb 2008 04:21:51 +0000 /blogs/joeydotnet/archive/2008/02/07/introducing-activesupport-net.aspx#comment-90 Cool idea, and Scott's comment was useful too. Cool idea, and Scott’s comment was useful too.

]]> By: joeyDotNet http://lostechies.com/joeybeninghove/2008/02/07/introducing-activesupport-net/#comment-89 joeyDotNet Fri, 08 Feb 2008 02:22:26 +0000 /blogs/joeydotnet/archive/2008/02/07/introducing-activesupport-net.aspx#comment-89 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. 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.

]]> By: Scott Bellware http://lostechies.com/joeybeninghove/2008/02/07/introducing-activesupport-net/#comment-88 Scott Bellware Fri, 08 Feb 2008 01:07:29 +0000 /blogs/joeydotnet/archive/2008/02/07/introducing-activesupport-net.aspx#comment-88 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. 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.

]]>