Context's .container deemed useless #53

Open
opened 2022-12-16 14:20:22 +00:00 by deavmi · 1 comment
Owner

What is Context?

The Context is passed around to indicate InitScope of an item and the container of such a thing. However, many parser nodes have a parentOf field, so this part of Context can actually be removed and is not needed.

I believe the reason it probably was added was I realised that things like Expression in the parser had no parent information and then I added this but everything then started using Context. What would be a good fix would be to remove the container field from Context and switch up dependency to be able to work with just that as it, literally copies it across.

For example, when we have a VariableDeclaration, something the parser could easily (and in this case probably already does) set the parent of, we call generalPass(module, context):

Context context = new Context(modulle, InitScope.STATIC);
DNode moduleDNode = generalPass(modulle, context);

THis could be retrived, for the variable declaration itself, by the first argument of generalPass which is a container.

We need to make sure everything is parented first in parser before such a switch can be made.

Original discussion

Notes

_ What was the reason for a Context object? Othee than for me to store InitScope

  • Like all entities have a Container which is where they live, and entity.setContext(context)
    really just contains that copy of the Container (an object reference).
  • I think it actually comes from having not used parentToContainer in situations like
    parseExpression() where we needed to localise like where it could be used.

Obviousl InitScope info was needed but we didn't like have parentOF() set for things
like expressions, hence it was added as an after thought.

We really could have done that, and passed Context only really as for
stuff like InitScopre. It shouldn't be a huge work around but I will do it later.

Thankfully we only use Context wherever we go in the dependency generator.

## What is `Context`? The `Context` is passed around to indicate InitScope of an item and the container of such a thing. However, many parser nodes have a `parentOf` field, so this part of Context can actually be removed and is not needed. I believe the reason it probably was added was I realised that things like `Expression` in the parser had no parent information and then I added this **but** everything then started using `Context`. What would be a good fix would be to remove the `container` field from `Context` and switch up dependency to be able to work with just that as it, literally copies it across. For example, when we have a VariableDeclaration, something the parser could easily (and in this case probably already does) set the parent of, we call `generalPass(module, context)`: ```d Context context = new Context(modulle, InitScope.STATIC); DNode moduleDNode = generalPass(modulle, context); ``` THis could be retrived, for the variable declaration itself, by the first argument of `generalPass` which **is** a container. We need to make sure everything is parented first in parser before such a switch can be made. ## Original discussion Notes _ What was the reason for a Context object? Othee than for me to store InitScope - Like all entities have a `Container` which is where they live, and `entity.setContext(context)` really just contains that copy of the Container (an object reference). - I think it actually comes from having not used `parentToContainer` in situations like `parseExpression()` where we needed to localise like where it could be used. Obviousl InitScope info was needed but we didn't like have `parentOF()` set for things like expressions, hence it was added as an after thought. We really could have done that, and passed Context only really as for stuff like InitScopre. It shouldn't be a huge work around but I will do it later. Thankfully we only use Context wherever we go in the dependency generator.
deavmi added the
dependency
parser
qol
labels 2022-12-16 14:20:31 +00:00
deavmi self-assigned this 2022-12-16 14:20:37 +00:00
deavmi added the
question
label 2022-12-19 09:43:28 +00:00
deavmi added this to the Dependency tree, type-checking and codegen project 2022-12-19 09:43:33 +00:00
Author
Owner

Bump

Bump
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tlang/tlang#53
No description provided.