There are definitely some things you are going to need to know about before you will understand all of what needed to be done for the conversion to C#/.NET4.

I'll add some real help to describe the ways that this version differs from what you can read about in the Java original, on the ECJ site at GMU. But for now, a few notes will have to do…


 

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

In ECJ the “*.param” files contain simple type assignments by namespace such as "ec.Population". At runtime the code directly instantiates a Population because that type name in the assignment corresponds directly to a type that is locatable (without any need for aliasing).

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real (.NET) type names before we can search for, and instantiate, each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...


An attribute, ECConfiguration, is attached to all types that might need to be specified in the configuration files (it does no harm, of course, to alias ANY type). A static class called ECActivator maps a canonical name, specified in the attribute, to a .NET type found in assemblies which are added at runtime.

For Example:

  namespace MyNamespace
  {
     [ECConfiguration("ec.MyType")]
     public class MyClass {}
  }

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

  public static Main(...)
  {
     // ... blah, blah, blah

     ECActivator.AddSourceAssembly(Assembly ecAssembly);
     ECActivator.AddSourceAssembly(Assembly myAssembly);

     // ... blah, blah, blah
  }

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And then I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)


 NOTES: "ARCHETYPES"

I'm really not sure why it is not a universal practice, but I usually create a separate assembly called "Archetype" for any non-trivial project (the suitability of the name seems remarkably obvious to me). In it go any types that have no outside dependencies aside from the standard "platform" provisions. This allows us to avoid many annoying circular reference problems that ultimately result in bad design as projects grow increasingly complex (when they begin to require more sophisticated factoring). The assembly should remain extremely lightweight no matter how large the project grows (because it is meant to hold mainly interfaces, enumerations, constants, and perhaps a few simple abstract base classes. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. There's nothing mystical about it. It's purpose is as simple as simple gets!

(To be fair, one often sees this kind of assembly popping up in a myriad of guises - usually named somthing like "contracts", which has slightly more speicalized implications. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

 


 

NOTES: "NAMESPACES"

While the algorithms and apparti provided by ECJ are central to the evolutionary optimization strategy in BraneCloud, there are additional namespaces currently taking shape in my private development branch. It would have been nice to tag this conversion with a simple name like ECCSharp, or something. But that would have created a disconnect from some of the extensions, integrations, and specializations that are planned. If, or when, I release some of these other things, it will become more obvious why added differentiation was required. For example, there are already other conversions in progress and original code existing under the following namespaces:

  • BraneCloud.Deduction
  • BraneCloud.Induction
  • BraneCloud.Presentation
  • BraneCloud.Representation
  • BraneCloud.Simulation
  • BraneCloud.Workflow
  • Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

 


 

 

 

(MORE NOTES LATER…)

Last edited May 26, 2011 at 10:57 PM by bstabile, version 17

Comments

No comments yet.