Deep Submodule nesting issues?

General
1

I am writing a project that has more closely related classes than I usually need.

As classes can not contain classes, putting them all at the same module nesting level is a nightmare for organization…

To organize them so I don’t get confused (Navigator ) I am nesting modules pretty deeply. I am naming super and subclasses the same but at different module levels, so at a glance one can see the relationships.

I know from a language/compiler view that should not be an issue… But what about from a practical standpoint with the IDE?

Will autocomplete get confused, the IDE slow down more or choke at some point?

Will execution speed be affected?

Thanks,
-karen

2

Karen, you have to test yourself. Are you creating thousands of classes? If not, why would you worry about an “unlaid egg”?

1 Like
3

Because I have a deadline and I am getting late so would not have time to rewrite again (navigator got too messy which was slowing me down and making it hard to write code so I am redoing it with little time)

-Karen

2 Likes
4

Folders?

A folder for a class with another folder in there for all the subclasses.

Eg

ClassA_Folder

ClassA
ClassA_SubclassesFolder

ClassA_Subclass1
ClassA_Subclass1_Folder
ClassA_Subclass1_Subclass1
ClassA_Subclass1_Subclass2

ClassA_Subclass2
ClassA_Subclass2_Folder
ClassA_Subclass2_Subclass1
ClassA_Subclass2_Subclass2

1 Like
5

P.S.I read somewhere that you should not make your hierarchy too deep as that might lead to problems, but don‘t quote me on that.

1 Like
6

The problem with the folder solution is that you can’t put folders in modules and I want it in a module to keep autocomplete lists from getting too big.

Though autocomplete is flakily with nested modules… although the complier gets it right, autocomplete often does not work unless one uses the full namespace hierarchy when one should not have to, in DIM s and property declarations

-Karen

7

Why would you even want to do that? You are thinking backwards about the organisation.

Folders are for organisation, modules for functionality.

Don‘t use modules in modules in modules.

8

Modules are for both actually. And folders have no effect on autocomplete lists but modules do.

A simple example from a small part of what I am working on… this is the module hierarchy for one part of it:

Microplate
       Abstract   ' Base classes etc for MicrotiterPlate Assay classes
       Endpoint  '  generic endpoint assay classes:  subclasses of Abstract
           Abstract  ' Base classes etc for kinetic assays 
       Kinetic  ' kinetic Assay base classes etc: subclasses of above
           Abstract  ' Base classes etc for kinetic assays 
           Velocity  ' Specific classes for Enzyme assays by initial velocity
9

Again. If you don’t make hundreds of classes then you make mountains out of molehills.