Changes to source code directory structures

[cpurdy]

Without breaking the current layout that we use today, we are planning to add a few new options to the hierarchical organization for Ecstasy source code.

Today, we support a "project style" module layout, and a "single file" module layout. For an example of the former, just see any of the "lib_" directories in the Ecstasy project. For an example of the latter, just see the various manual test modules.

In the project style layout, the module itself is always named "module.x", and is located in the root directory of the project. Similarly, package implementations are always named "package.x", and are located inside the directory that has the package name. So a module Test with a package util would look like:

    Test/
     |- module.x
     |- SomeClass.x
     |- util/
         |- package.x
         |- AnotherClass.x

We're now introducing a simpler, uniform nesting structure. For example, the above could be re-organized as:

    ./
    |- Test.x
    |- Test/
         |- SomeClass.x
         |- util.x
         |- util/
             |- AnotherClass.x

• It would be a compile time error to have both ./NameOfModule.x and ./NameOfModule/module.x.
• It would be a compile time error to have both ./NameOfPackage.x and ./NameOfPackage/package.x.
• Walking up a directory tree to find the module would have to be modified; currently, it just looks for a module.x file.

Additionally, this structure can now be used for any class, and not just modules and packages. This allows nested classes to be separated into individual files, instead of all being in one large file. This is particularly useful for large and complex nesting of virtual child classes.

Consider the jsonDB example:

    x/
     |- module.x
     |- Client.x (a very large file)
     |- ...

This may get split out something like

    x/
     |- module.x
     |- Client.x
     |- Client/
          |- DBObjectImpl.x
          |- Connection.x
          |- Transaction.x
          |- DBMap.x
          |- DBProcessor.x
          |- DBLog.x
          |- ... (etc)
     |- ...

[cpurdy]

I'm starting to think that, if we do this, we should just drop the old "module.x" and "package.x" approach altogether.

[cpurdy]

OK, this change has been made now.

Temporarily, we still support the old organizational structure as well. JK - I didn't touch the web project structure, because with a separate branch I didn't want to inflict unnecessary pain :)

Let's give it a few days (or weeks) and see how it feels.

The only real issue that I ran into was that the JSON project had both a "mapping" package and a "Mapping" class in the same namespace (i.e. nested directly under the module), and thus it needed a Mapping.x and a mapping.x file (obviously not allowed).

[cpurdy]

To close this topic:

• The new organizational structure has now been in place for some time and working well.
• The old organizational structure is no longer supported and the supporting code has been removed.