Organizing namespaces

Developer
Jan 24, 2011 at 4:30 PM

We have noticed that we need to improve the architecture of this project, such as putting all of the Transforms into DotSpatial.Projections.Transforms instead of letting them hang out with everything else in  DotSpatial.Projections. Small changes like this may not be perfect at first, but can be refined up until our first official release. Feel free to comment on the organization effort.

Developer
Jan 24, 2011 at 4:41 PM

Sounds good.  Have fun =).

 

Ted

Developer
Jan 24, 2011 at 7:26 PM

The ribbon, toolstrip, and statusstrip have been moved to DotSpatial.Controls.Bars

Developer
Jan 24, 2011 at 8:53 PM

I won't stop you if you think it improves things... but I'm not sure about it myself.  A good thing to keep in mind as you are doing this, in case you are not already, is that since we keep the same namespace as we are folders, the number one criteria for the framework is how well the locations work as a namespace.  How the files look on your drive is of zero concern comparatively.  When you do DotSpatial.Controls and then hit . what will developers be looking at.  It is a balance between making things as easy to find as possible, while still keeping things as easy to use as possible.  So things like grouping transforms make a lot of logical sense since they clutter up the namespace, they are all basically the same kind of thing and very obviously transforms, and they are not part of the mainline scenario, which is basically working with Reproject, ProjectionInfo, GeographicInfo, Datum, Meridian, LinearUnit, AngularUnit, and Spheroid.

The grouping into Bars... much less so.  That starts to feel like you are making a grouping just because you want a hierarchy to clean up the folder structure on the drive.  I originally had this deeply nested set of hierarchical organization for all the classes into folders, the way you would organize files in folders.  The goal of the hierarchy was to keep a low number of files in each category so you can view them better in your browser.  The problem was that the way I chose to group things was not very intuitive to other people.  It taught me that no matter how you choose to group things, it is non-obvious to someone else.   Also, remember each one of these sub-namespaces comes along with yet another associated "using" expression at the top of every single class that uses it, or else a tedious written full path to use the class.  When you work with the controls in System.Windows.Forms, do you need to add a reference to System.Windows.Forms.Bars to do it?  No.  Think of how many hundreds of classes must be sitting right in that root namespace.  Microsoft almost doesn't use sub-namespaces themselves.  Pretty much everything in your mainline scenario should go in the root namespace.  Sub-namespaces should be reserved for advanced or seldom used scenarios where adding an extra using is no big deal.

You also want to make sure that any grouping that you do accomplish is super super obvious.  It is not obvious to me why you are calling it "Bars" when none of the controls you are putting in "Bars" have "bar" in their name while something like SpatialProgressBar, which does have Bar in its name, is not being added.  In fact, I don't see an obvious connection for Bar aside for the outdated concept of a "toolbar" which is a name that technically isn't used anymore.  I personally won't want to have to add a using reference with "Bar" at the top just to use the ribbon or toolstrip control.  It sounds like the only reason for the sub-namespace is that we have about 50 ribbon related classes, and it might be nice to clean up that clutter by having a "Ribbon" sub-namespace.  But as you may have realized, you should never have the namespace with the same name as the control itself.  So Map should not exist in a namespace named Map.  This will cause massive confusion.  Up until now we have solved this by keeping the prefix "Ribbon" in front of those classes, so that they clump together in the root namespace. 

In the case of the ribbon, I think the mainline scenario requires you to be able to add buttons, drop-downs, tabs and groups etc.  So in other words, if you work with the ribbon programmatically, most of the extra classes are still part of your mainline scenario with it.  If you want to sub-group it, it might be ok if you had a Ribbon folder and then renamed the control RibbonControl or something.  It fits with everything else that has a prefix like RibbonButton etc.  The only downside is now you have things like DotSpatial.Controls.Ribbon.RibbonButton, which sounds a little redundant.  Another option is to have a "GlassRibbon" folder, and then keep all the other names the same, so that we can in the future have different types of ribbons go in a sub-folder named appropriately.  Finally, you could have a "Ribbons" subfolder, but I don't recommend this unless you plan on supporting other ribbon variants.

Anyway, I want you to have the freedom and power to improve things here, so I'm not stopping you from doing anything, I just want you to get the benefit of some hard learned lessons that I went through myself, so we don't end up repeating any mistakes.  Good luck.

Ted

 

Coordinator
Jan 25, 2011 at 12:23 AM
Ted, thanks for these excellent insights. I agree with the Transforms sub namespace, and do generally like the idea of anything that makes the code more readable and the organization easier to understand (since I need to attract more volunteers who can get up and running quickly!) Your point about bars is pretty good. I do like the idea of moving all the ribbon stuff into a single spot though. So what about dropping the "Ribbon" prefix for the controls that are part of the Ribbon, but putting them under Dotspatial.Controls.RibbonControls.xxx So that you'd have DotSpatial.Controls.RibbonControls.Button. But have the actual Ribbon itself at the root of the Controls space. Is that weird? The idea is that the "Controls" space would have a dozen of the most important controls and the smaller ones would be in sub namespaces... Is this bad?

On Mon, Jan 24, 2011 at 2:53 PM, shade1974 <notifications@codeplex.com> wrote:

From: shade1974

I won't stop you if you think it improves things... but I'm not sure about it myself. A good thing to keep in mind as you are doing this, in case you are not already, is that since we keep the same namespace as we are folders, the number one criteria for the framework is how well the locations work as a namespace. How the files look on your drive is of zero concern comparatively. When you do DotSpatial.Controls and then hit . what will developers be looking at. It is a balance between making things as easy to find as possible, while still keeping things as easy to use as possible. So things like grouping transforms make a lot of logical sense since they clutter up the namespace, they are all basically the same kind of thing and very obviously transforms, and they are not part of the mainline scenario, which is basically working with Reproject, ProjectionInfo, GeographicInfo, Datum, Meridian, LinearUnit, AngularUnit, and Spheroid.

The grouping into Bars... much less so. That starts to feel like you are making a grouping just because you want a hierarchy to clean up the folder structure on the drive. I originally had this deeply nested set of hierarchical organization for all the classes into folders, the way you would organize files in folders. The goal of the hierarchy was to keep a low number of files in each category so you can view them better in your browser. The problem was that the way I chose to group things was not very intuitive to other people. It taught me that no matter how you choose to group things, it is non-obvious to someone else. Also, remember each one of these sub-namespaces comes along with yet another associated "using" expression at the top of every single class that uses it, or else a tedious written full path to use the class. When you work with the controls in System.Windows.Forms, do you need to add a reference to System.Windows.Forms.Bars to do it? No. Think of how many hundreds of classes must be sitting right in that root namespace. Microsoft almost doesn't use sub-namespaces themselves. Pretty much everything in your mainline scenario should go in the root namespace. Sub-namespaces should be reserved for advanced or seldom used scenarios where adding an extra using is no big deal.

You also want to make sure that any grouping that you do accomplish is super super obvious. It is not obvious to me why you are calling it "Bars" when none of the controls you are putting in "Bars" have "bar" in their name while something like SpatialProgressBar, which does have Bar in its name, is not being added. In fact, I don't see an obvious connection for Bar aside for the outdated concept of a "toolbar" which is a name that technically isn't used anymore. I personally won't want to have to add a using reference with "Bar" at the top just to use the ribbon or toolstrip control. It sounds like the only reason for the sub-namespace is that we have about 50 ribbon related classes, and it might be nice to clean up that clutter by having a "Ribbon" sub-namespace. But as you may have realized, you should never have the namespace with the same name as the control itself. So Map should not exist in a namespace named Map. This will cause massive confusion. Up until now we have solved this by keeping the prefix "Ribbon" in front of those classes, so that they clump together in the root namespace.

In the case of the ribbon, I think the mainline scenario requires you to be able to add buttons, drop-downs, tabs and groups etc. So in other words, if you work with the ribbon programmatically, most of the extra classes are still part of your mainline scenario with it. If you want to sub-group it, it might be ok if you had a Ribbon folder and then renamed the control RibbonControl or something. It fits with everything else that has a prefix like RibbonButton etc. The only downside is now you have things like DotSpatial.Controls.Ribbon.RibbonButton, which sounds a little redundant. Another option is to have a "GlassRibbon" folder, and then keep all the other names the same, so that we can in the future have different types of ribbons go in a sub-folder named appropriately. Finally, you could have a "Ribbons" subfolder, but I don't recommend this unless you plan on supporting other ribbon variants.

Anyway, I want you to have the freedom and power to improve things here, so I'm not stopping you from doing anything, I just want you to get the benefit of some hard learned lessons that I went through myself, so we don't end up repeating any mistakes. Good luck.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani@isu.edu
geology.isu.edu
www.mapwindow.org


Developer
Jan 25, 2011 at 3:22 PM
I like the idea better than having a Bars namespace. I think it might work better to have the Ribbon named as Ribbon within the RibbonControls namespace though. Certainly you could remove the Ribbon prefix... just remember what happens if you have a using reference to System.Windows.Forms at the top as well as a reference to DotSpatial.Controls.RibbonControls. It will mean that "Button" and others would suddenly be ambiguous. This is a frustrating situation for coders. It means you need yet ANOTHER using reference like:

using Button = DotSpatial.Controls.RibbonControls.Button;

Then after that if you ever want to reference a Windows forms button you have to type out the full reference System.Windows.Forms.Button. Without the using, both references have to be spelled out with complete paths to clear up the ambiguity. If you have others in the list that are ambiguous it starts getting really annoying. We are already sort of stuck with this ambiguity between System.Drawing.Point and DotSpatial.Geometry.Point, so I don't recommend dropping the ribbon prefix, even if you group it into a subfolder. Also, updating a single using expression at the top is easier for our existing coders to do in order to keep in synch with the changes than changing class names.

The decision as to whether to put the ribbon control itself doesn't have a right answer. The advantage of having the ribbon in the main path is that users can see right away that we have a ribbon control and can find it. I think it would not be hard to find the other components in a folder called RibbonControls, and not that big a deal to add a reference in order to do sophisticated ribbon stuff. The other side of the argument is that if you ONLY want to work with the ribbon, it might be nice to have the control and everything you need to set up the control handled by a single using reference at the top to DotSpatial.Controls.RibbonControls. It might in fact be better to put the ribbon in the RibbonControls sub-path with its components. That way its also compartmentalized. If you want to add a different ribbon control later, there won't be confusion as to which RibbonButton goes with what ribbon and so on.

Anyway, it's up to you, but just remember that ambiguity is bad.

Ted






On Mon, Jan 24, 2011 at 5:23 PM, danames <notifications@codeplex.com> wrote:

From: danames

Ted, thanks for these excellent insights. I agree with the Transforms sub namespace, and do generally like the idea of anything that makes the code more readable and the organization easier to understand (since I need to attract more volunteers who can get up and running quickly!) Your point about bars is pretty good. I do like the idea of moving all the ribbon stuff into a single spot though. So what about dropping the "Ribbon" prefix for the controls that are part of the Ribbon, but putting them under Dotspatial.Controls.RibbonControls.xxx So that you'd have DotSpatial.Controls.RibbonControls.Button. But have the actual Ribbon itself at the root of the Controls space. Is that weird? The idea is that the "Controls" space would have a dozen of the most important controls and the smaller ones would be in sub namespaces... Is this bad?

On Mon, Jan 24, 2011 at 2:53 PM, shade1974 <notifications@codeplex.com> wrote:

From: shade1974

I won't stop you if you think it improves things... but I'm not sure about it myself. A good thing to keep in mind as you are doing this, in case you are not already, is that since we keep the same namespace as we are folders, the number one criteria for the framework is how well the locations work as a namespace. How the files look on your drive is of zero concern comparatively. When you do DotSpatial.Controls and then hit . what will developers be looking at. It is a balance between making things as easy to find as possible, while still keeping things as easy to use as possible. So things like grouping transforms make a lot of logical sense since they clutter up the namespace, they are all basically the same kind of thing and very obviously transforms, and they are not part of the mainline scenario, which is basically working with Reproject, ProjectionInfo, GeographicInfo, Datum, Meridian, LinearUnit, AngularUnit, and Spheroid.

The grouping into Bars... much less so. That starts to feel like you are making a grouping just because you want a hierarchy to clean up the folder structure on the drive. I originally had this deeply nested set of hierarchical organization for all the classes into folders, the way you would organize files in folders. The goal of the hierarchy was to keep a low number of files in each category so you can view them better in your browser. The problem was that the way I chose to group things was not very intuitive to other people. It taught me that no matter how you choose to group things, it is non-obvious to someone else. Also, remember each one of these sub-namespaces comes along with yet another associated "using" expression at the top of every single class that uses it, or else a tedious written full path to use the class. When you work with the controls in System.Windows.Forms, do you need to add a reference to System.Windows.Forms.Bars to do it? No. Think of how many hundreds of classes must be sitting right in that root namespace. Microsoft almost doesn't use sub-namespaces themselves. Pretty much everything in your mainline scenario should go in the root namespace. Sub-namespaces should be reserved for advanced or seldom used scenarios where adding an extra using is no big deal.

You also want to make sure that any grouping that you do accomplish is super super obvious. It is not obvious to me why you are calling it "Bars" when none of the controls you are putting in "Bars" have "bar" in their name while something like SpatialProgressBar, which does have Bar in its name, is not being added. In fact, I don't see an obvious connection for Bar aside for the outdated concept of a "toolbar" which is a name that technically isn't used anymore. I personally won't want to have to add a using reference with "Bar" at the top just to use the ribbon or toolstrip control. It sounds like the only reason for the sub-namespace is that we have about 50 ribbon related classes, and it might be nice to clean up that clutter by having a "Ribbon" sub-namespace. But as you may have realized, you should never have the namespace with the same name as the control itself. So Map should not exist in a namespace named Map. This will cause massive confusion. Up until now we have solved this by keeping the prefix "Ribbon" in front of those classes, so that they clump together in the root namespace.

In the case of the ribbon, I think the mainline scenario requires you to be able to add buttons, drop-downs, tabs and groups etc. So in other words, if you work with the ribbon programmatically, most of the extra classes are still part of your mainline scenario with it. If you want to sub-group it, it might be ok if you had a Ribbon folder and then renamed the control RibbonControl or something. It fits with everything else that has a prefix like RibbonButton etc. The only downside is now you have things like DotSpatial.Controls.Ribbon.RibbonButton, which sounds a little redundant. Another option is to have a "GlassRibbon" folder, and then keep all the other names the same, so that we can in the future have different types of ribbons go in a sub-folder named appropriately. Finally, you could have a "Ribbons" subfolder, but I don't recommend this unless you plan on supporting other ribbon variants.

Anyway, I want you to have the freedom and power to improve things here, so I'm not stopping you from doing anything, I just want you to get the benefit of some hard learned lessons that I went through myself, so we don't end up repeating any mistakes. Good luck.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani@isu.edu
geology.isu.edu
www.mapwindow.org


Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Jan 25, 2011 at 7:26 PM
OK, I like the idea of

DotSpatial.Controls.RibbonControls.Ribbon
DotSpatial.Controls.RibbonControls.RibbonButton
DotSpatial.Controls.RibbonControls.RibbonFoo

mudnug will you please try this rearrangement for the Ribbon at least?

- Dan

On Tue, Jan 25, 2011 at 9:22 AM, Shade1974 <notifications@codeplex.com> wrote:

From: Shade1974

I like the idea better than having a Bars namespace. I think it might work better to have the Ribbon named as Ribbon within the RibbonControls namespace though. Certainly you could remove the Ribbon prefix... just remember what happens if you have a using reference to System.Windows.Forms at the top as well as a reference to DotSpatial.Controls.RibbonControls. It will mean that "Button" and others would suddenly be ambiguous. This is a frustrating situation for coders. It means you need yet ANOTHER using reference like:

using Button = DotSpatial.Controls.RibbonControls.Button;

Then after that if you ever want to reference a Windows forms button you have to type out the full reference System.Windows.Forms.Button. Without the using, both references have to be spelled out with complete paths to clear up the ambiguity. If you have others in the list that are ambiguous it starts getting really annoying. We are already sort of stuck with this ambiguity between System.Drawing.Point and DotSpatial.Geometry.Point, so I don't recommend dropping the ribbon prefix, even if you group it into a subfolder. Also, updating a single using expression at the top is easier for our existing coders to do in order to keep in synch with the changes than changing class names.

The decision as to whether to put the ribbon control itself doesn't have a right answer. The advantage of having the ribbon in the main path is that users can see right away that we have a ribbon control and can find it. I think it would not be hard to find the other components in a folder called RibbonControls, and not that big a deal to add a reference in order to do sophisticated ribbon stuff. The other side of the argument is that if you ONLY want to work with the ribbon, it might be nice to have the control and everything you need to set up the control handled by a single using reference at the top to DotSpatial.Controls.RibbonControls. It might in fact be better to put the ribbon in the RibbonControls sub-path with its components. That way its also compartmentalized. If you want to add a different ribbon control later, there won't be confusion as to which RibbonButton goes with what ribbon and so on.

Anyway, it's up to you, but just remember that ambiguity is bad.

Ted






On Mon, Jan 24, 2011 at 5:23 PM, danames <notifications@codeplex.com> wrote:

From: danames

Ted, thanks for these excellent insights. I agree with the Transforms sub namespace, and do generally like the idea of anything that makes the code more readable and the organization easier to understand (since I need to attract more volunteers who can get up and running quickly!) Your point about bars is pretty good. I do like the idea of moving all the ribbon stuff into a single spot though. So what about dropping the "Ribbon" prefix for the controls that are part of the Ribbon, but putting them under Dotspatial.Controls.RibbonControls.xxx So that you'd have DotSpatial.Controls.RibbonControls.Button. But have the actual Ribbon itself at the root of the Controls space. Is that weird? The idea is that the "Controls" space would have a dozen of the most important controls and the smaller ones would be in sub namespaces... Is this bad?

On Mon, Jan 24, 2011 at 2:53 PM, shade1974 <notifications@codeplex.com> wrote:

From: shade1974

I won't stop you if you think it improves things... but I'm not sure about it myself. A good thing to keep in mind as you are doing this, in case you are not already, is that since we keep the same namespace as we are folders, the number one criteria for the framework is how well the locations work as a namespace. How the files look on your drive is of zero concern comparatively. When you do DotSpatial.Controls and then hit . what will developers be looking at. It is a balance between making things as easy to find as possible, while still keeping things as easy to use as possible. So things like grouping transforms make a lot of logical sense since they clutter up the namespace, they are all basically the same kind of thing and very obviously transforms, and they are not part of the mainline scenario, which is basically working with Reproject, ProjectionInfo, GeographicInfo, Datum, Meridian, LinearUnit, AngularUnit, and Spheroid.

The grouping into Bars... much less so. That starts to feel like you are making a grouping just because you want a hierarchy to clean up the folder structure on the drive. I originally had this deeply nested set of hierarchical organization for all the classes into folders, the way you would organize files in folders. The goal of the hierarchy was to keep a low number of files in each category so you can view them better in your browser. The problem was that the way I chose to group things was not very intuitive to other people. It taught me that no matter how you choose to group things, it is non-obvious to someone else. Also, remember each one of these sub-namespaces comes along with yet another associated "using" expression at the top of every single class that uses it, or else a tedious written full path to use the class. When you work with the controls in System.Windows.Forms, do you need to add a reference to System.Windows.Forms.Bars to do it? No. Think of how many hundreds of classes must be sitting right in that root namespace. Microsoft almost doesn't use sub-namespaces themselves. Pretty much everything in your mainline scenario should go in the root namespace. Sub-namespaces should be reserved for advanced or seldom used scenarios where adding an extra using is no big deal.

You also want to make sure that any grouping that you do accomplish is super super obvious. It is not obvious to me why you are calling it "Bars" when none of the controls you are putting in "Bars" have "bar" in their name while something like SpatialProgressBar, which does have Bar in its name, is not being added. In fact, I don't see an obvious connection for Bar aside for the outdated concept of a "toolbar" which is a name that technically isn't used anymore. I personally won't want to have to add a using reference with "Bar" at the top just to use the ribbon or toolstrip control. It sounds like the only reason for the sub-namespace is that we have about 50 ribbon related classes, and it might be nice to clean up that clutter by having a "Ribbon" sub-namespace. But as you may have realized, you should never have the namespace with the same name as the control itself. So Map should not exist in a namespace named Map. This will cause massive confusion. Up until now we have solved this by keeping the prefix "Ribbon" in front of those classes, so that they clump together in the root namespace.

In the case of the ribbon, I think the mainline scenario requires you to be able to add buttons, drop-downs, tabs and groups etc. So in other words, if you work with the ribbon programmatically, most of the extra classes are still part of your mainline scenario with it. If you want to sub-group it, it might be ok if you had a Ribbon folder and then renamed the control RibbonControl or something. It fits with everything else that has a prefix like RibbonButton etc. The only downside is now you have things like DotSpatial.Controls.Ribbon.RibbonButton, which sounds a little redundant. Another option is to have a "GlassRibbon" folder, and then keep all the other names the same, so that we can in the future have different types of ribbons go in a sub-folder named appropriately. Finally, you could have a "Ribbons" subfolder, but I don't recommend this unless you plan on supporting other ribbon variants.

Anyway, I want you to have the freedom and power to improve things here, so I'm not stopping you from doing anything, I just want you to get the benefit of some hard learned lessons that I went through myself, so we don't end up repeating any mistakes. Good luck.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani@isu.edu
geology.isu.edu
www.mapwindow.org


Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani@isu.edu
geology.isu.edu
www.mapwindow.org