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.