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.