I was very happy to see this project here, and have been following it for some time now. Unfortunately, I had to realize that it seems to be stuck here and does not continue properly. One could almost give the impression that nothing more is happening here.

Therefore I wanted to inform myself about the state of affairs and if there are plans to reoccupy and complete the project.

Can I suggest that we make the ALObjectParser a separate, static and stateless class (ALObjectParser)? The only thing it should do, as far as I'm concerned, is something like this:

static IEnumerable<ALObject> Read(string path)

I chose an IEnumerable as the return value type since a file could contain >1 object. For writing, I think we need the mirrored version, again in a separate, static and stateless class (ALObjectWriter?)

static void Write(IEnumerable<ALObject> objects, string path)

Placeholder task for discussion

New class: ALTableParser: ALObjectParser
Function: Parse AL Table objects into SymbolReference stucture

Let's keep ALCodeunit clean; implement ATDD-related stuff in C# extension methods, e.g.

// only retrieve names (cheap and sometimes all you want to know)
static IEnumerable<string> GetFeatureNames(this ALCodeunit codeunit) 

// retrieve feature details
static ALFeature GetFeature(this ALCodeunit codeunit, string featureName) 

// add new feature
static ALCodeunit AddFeature(this ALCodeunit codeunit, ALFeature feature)

// remove feature
static ALCodeunit RemoveFeature(this ALCodeunit codeunit, string featureName)

In ALObjectParser, allow objects and subobjects to have comments associated with them, e.g.:

• codeunits: the comment lines that preceed the properties of the codeunit, e.g. our features
• methods: the comment lines between the procedure signature and begin/var
• code lines: the comment lines immediately preceding them (?)
  That way, the comments that differentiate ATDD codeunits from normal codeunits can easily be retrieved and interpreted.

Ideally, perhaps, to make sure we don't mix ALObjectParser and ATDD concepts, implement the ATDD features as separate library (with a dependency on ALObjectParser). That way, ALObjectParser cannot know about ATDD, but ATDD knows about ALObjectParser.

Should we perhaps invest more in keeping the object model consistent, e.g. give TestFeature a constructor that requires a valid name? In that case, I think I would consider making the Name property read-only.

There is a lot to be said for entirely immutable objects, i.e. objects that receive their "state"
as constructor parameters and cannot be modified after construction, especially if you
plan to later parallelize (parts of) the parsing.

Issue details

Placeholder task for discussion

New class: ALPageParser: ALObjectParser
Function: Parse AL Page objects into SymbolReference stucture