One of the unique capabilities of Regionize process engine of Smarties 2008 is that it can Regionize a single member too.

I made it a principal of mine that the Regionize feature of Smarties 2008 must support this capability. I didn’t have a use for it at the time of my decision and obviously couldn’t see all the conditions (thousands of them) at the time but I normally get a distinctive feeling about something from time to time that tells me if I should do something or not.

I’m very pleased to say once again my distinctive feeling worked out as a reliable tool for me. In fact Regionizing a single member has become a vital capability for Smarties 2008 itself and very convenient for its users.

If you have used Smarties 2008 in the past and happen to know about other productivity tools then obviously you must have realised most tools wouldn’t Regionize the newly created members by the tool itself but 99% of the cases Smarties 2008 does. This means when you are using other tools that have similar refactoring features for instance you are left with the job of Regionizing the members by yourself. If this is a one off job then I wouldn’t complain about it either but when you are doing it as a routine in your new projects it becomes annoying and time consuming.

Picture this scenario if you will, you would Regionize a class first then manually add your own custom #regions to them. For instance under the #region Method Members you would create a child region named BL Methods. If you to Regionize the same class again the BL Methods will disappear because it was listed under a parent region that the Regionize process engine considered it as its own. In such scenarios you have to re-create your custom #regions again. Annoying isn’t it?

I haven’t assumed users would never create custom-regions inside the regions that the Regionize process creates. Therefore if you are adding new members by hand you can Regionize them without losing all your custom #regions. However, you would still lose the custom regions by the Regionize process engine too but only under the root region where the member is moved to, I’ll explain why that is shortly.

Any tools that don’t support Single Member Regionization would lose all the custom-regions under the root regions that it created unless the regions are being marked by a symbol to avoid that. Smarties 2008 never removes custom-regions that are placed in root of a type definition during the Regionization and also never mark regions with symbols to tell them apart.

Personally I never liked the idea of enforcing my users to Regionize the entire class because a new member is added. Once again my distinctive feeling says there are users out there that they wouldn’t want to Regionize the entire class more than once. Beside the point, would you reconstruct the whole building from scratch if you wanted to add a wall in one of the rooms?

The Regionize process engine reconstructs only the root region and its child regions where the single member is going to be moved to. Do you recall the constraint values and other conditions such as the sorting orders that you can apply to different members from The Regionize Process in Smarties 2008 post?

When you are adding a new member to an existing root region it may or may not meet the constraint values that you have specified also you might have changed the constraint value since the root region was created. For this the Regionize process engine reads the entire members and adds the new member to be processed to figure out how members need to be grouped and listed. The finishing result would be exactly as if you Regionized the entire class again without actually doing it.

As you might know I have recently added a new grouping kind called Field-Property to the Regionize process engine. This grouping kind lists encapsulated fields along with their properties under a separate root region. Single Member Regionization can even support this group kind.

Since Single Member Regionization can be a vital capability for some users I’d try to see how I can preserve the user-created regions inside of the root regions that are created by the Regionize process engine in the near future.

I had identified two main issues with organising members soon after I started working on the Regionize process:

1. Every member kind that can be described is unique in its own rights.
2. Type Definitions cannot have the same Regionize profile or Code Layout.

1. Every member kind that can be described is unique in its own rights

Member kinds cannot be seen as the same because they have different characteristics while not compiled. A property with getter and setter are two methods when the project is compiled but in your code files you can easily distinguish between a property and a method. 

Due to this fact every single member kind is handled by different part of the process engine to ensure maximum flexibility and extendibility. For instance Custom Events are handled totally differently than Non-Custom events. 

Even though event-handlers are methods the Regionize process can see them as different kind of member that it needs its own unique way of grouping. Event-handlers have common characteristics in how they are named. The names can be split into two identifiers. The first part tells the type the event is a member of and the second part tells the name of the event itself. The Regionize process engine can optionally group and list the event-handlers by the type the events are a member of. 

I hope using the above examples gave you the idea how actually member kinds are different and how the same member kind can be seen as different member kind that needs it own way of listing and grouping.

2. Type Definitions cannot have the same Regionize profile or Code Layout

To explain this better I have to talk about grouping members a bit first. If we use Methods as an example, we can group this member kind in the following ways; 

1. By Visibility
2. By Abstract (MustOverride in Visual Basic)
3. By Override
4. By Overload
5. By Interface Implementation
6. By Virtual (Overridable in Visual Basic)
7. By Access Scope (Instance or Static/Shared)
8. By custom constraints such as the attributes the method declared

Smarties 2008 currently does not support No. 8 grouping but it has been scheduled to add supports for 1.1 version release. 

All of the above method groupings would be listed under a parent #region. For instance to Group methods by their visibilities you would have a parent #region called Method Members and for public methods you would get a child #region called Public Methods. For abstract grouping a parent #region called Abstract Members is created then all methods would be listed under Method Members.

Now that you have the idea what I mean by grouping members we can go back to the second issue. 

I always use Microsoft Enterprise Library projects as an example when I want to talk about the real world example. When you have a single Regionize profile or Code Layout that describes how members are grouped then the same rules is applied for each Class, Structures and interfaces in your projects. The Microsoft Enterprise Library solution contains nearly 3,500 .cs files.

Obviously when you get into Regionizing your members you would get to this point where you do not want to apply the same kind of grouping to all type definitions in the project. For instance, would you want a class that has methods with public visibility only to be grouped and listed under the Public Methods #region? Of course you wouldn’t but the Regionize Profile/Code Layout will do it if the option was enabled.

My first attempt to solve this problem was by introducing profile management where you would create a profile and then add the code files that you would wanted to be Regionized against it. 

Even though I worked on this feature very hard without being regretted I have taken it out from Smarties 2008. There are things that would look good in theory but in real world they are so impractical and my approach was one of them. The Microsoft Enterprise Library solution was the reason that I knew for sure Regionize Profiles or Code Layouts wouldn’t be a practical solution because as a user point of view I had to create dozens of profiles or code layouts to cover a big solution like Microsoft Enterprise Library.

Smarties 2008 meant to be all about productivity and I noticed the Profiling approach would actually decrease productivity by forcing the developers to create and manage the profiles or to force them to accept a single profile for life. Even though in my approach the developers didn’t have to learn anything to setup a profile I still found it too much to accept the whole thing. The developers that I have worked with during Smarties 2008 development had neither the time nor the patience let alone wanting them to do the extra work for something that meant to be automated.

To solve this problem I came up with the idea of introducing a constraint to each process that creates a #region. The constraint is an integer value that represents the number of members, the number of visibility kinds, the number of member kinds, and so on.

Going back to the Methods again, you can now instruct the Regionize process engine to group methods by Method Visibility only if there is n number or more visibility kinds to be found. This only means when you are Regionizing from a single Type Definition to the entire solution the constraints are checked against every Type Definitions and the Regionize process engine can group members differently with a single call.

I have implemented the same idea over all kind of members that can be described. Setting up the conditions is as easy as checking and unchecking boxes or increasing or decreasing the constraint values. During the total rewrites of the engine I have also added supports so that users can specify their own sort orders almost for everything the Regionize process engine does. In my humble opinion the way the current Regionize process engine works will cover over 95% of your needs which it has been the goal so far. As I have mentioned earlier I have scheduled to build more feature into the Regionize process engine to increase its capabilities and usability.

Happy Regionization with Smarties 2008

In the next blog post I’ll talk about Single Member Regionization.