---
title: Dependency generation
date: 2021-08-11
author: Tristan B. Kildaire
tags: [typechecking, dependency, static, oop, tree]
---

# Dependency generation


## Working dependency generation (so far)

Just a quick update. I have started, I'd say about two months ago maybe, working on the dependency tree generaiton and it is working. This tree
represents the order of initialization of entities and when completed in its construction it will be used for code generation simply by
traversing down the tree.

Currently we parse the syntax tree generated by the parser and generate a new tree with components that contain a reflection or ressemblance rather
to their syntactic counterpart but with more information, such as has the node been visited already etc.

An example of this is done if you checkout to the commit `06dbf479ffdfdfa7b2f314a6f2860c75e16bb52f` on branch `typecheck_refactor` and run the following:

```bash
dub build --force
./tlang compile source/tlang/testing/typecheck/basic_dependence_correct1.t
```

This will run on the source file below:

```d
module typeChecking1;

A aInstance;
B bInstance;
int k;

class A
{
    static int pStatic;
    static B bInstanceStatic;
    static A aInstanceStaticMoi;

    int poes;
}

class B
{
    static int jStatic;
    static A aInstanceStatic;
}
```

And will output the following:

```
bruh
      (S) typeChecking1.aInstance
         typeChecking1.A
            (S) typeChecking1.A.pStatic
            (S) typeChecking1.A.bInstanceStatic
               typeChecking1.B
                  (S) typeChecking1.B.jStatic
                  (S) typeChecking1.B.aInstanceStatic
            (S) typeChecking1.A.aInstanceStaticMoi
      (S) typeChecking1.bInstance
      (S) typeChecking1.k
```

Which if we look at it shows the correct initialization of that code. We first init the module (implicit so far). Then we see that `aInstance` needs to be declared, so we init it, as it is `static`, but because it refers to a class type, `A`, we must statically initialize that class too (initilizing its `static` entities). So we init `typeChecking1.A` (our class), as you can see we then initialize the `pStatic`, which needs no further initlaization, then we do `bInstanceStatic`, this must init class `B`, so we do that,
but you see there would be a loop now, but because when we enter `A` for its static initlaization we set it as visited we know therefore it is busy initting and we should not re-init it (we are basically a dependency of it), then we init `jStatic` and return.

As you can see there is not dependency on `bInstance` on class `B` as it would have already been initted, and `k` didn't require anything to be initted but itself.

## More exmaples

There is another more complex example ending in `2`, same test case directory.