### Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook (preview only)

### Author Topic: Can't we get rid off circular unit reference?  (Read 7566 times)

#### Ñuño_Martínez

• Hero Member
• Posts: 932
##### Re: Can't we get rid off circular unit reference?
« Reply #15 on: February 12, 2018, 01:42:20 pm »
Pascal was designed with top-down/bottom-up design in mind.  I like this way of working.  Circular reference is a consequence of that design, and I think it is good because it forces you to think better solutions (better because they're more encapsulated and errors will have less propagation.  I hope you understand me).

My 2 cents.
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

• Hero Member
• Posts: 9400
##### Re: Can't we get rid off circular unit reference?
« Reply #16 on: February 12, 2018, 01:43:46 pm »
Getting rid of circular references?
It may be that unitA causes a circular reference and the same re-declaration in unitB doesn't?
Think logically... Can you prevent that with your proposal? NO.  Depends on unit order.
also related to equus asinus.

• Hero Member
• Posts: 9400
##### Re: Can't we get rid off circular unit reference?
« Reply #17 on: February 12, 2018, 01:45:03 pm »
Pascal was designed with top-down/bottom-up design in mind.  I like this way of working.  Circular reference is a consequence of that design, and I think it is good because it forces you to think better solutions (better because they're more encapsulated and errors will have less propagation.  I hope you understand me).

My 2 cents.
Indeed. It is also - often, not always - a warning for bad design: insufficient code separation. Most circular references can be factored out.
also related to equus asinus.

#### marcov

• Global Moderator
• Hero Member
• Posts: 7804
##### Re: Can't we get rid off circular unit reference?
« Reply #18 on: February 12, 2018, 01:53:42 pm »
Yes, but this is another issue. I unfortunately do not see what this has to do with my topic?

Your title is more generic (all types) than the discussion (reference class types only, later limited also to a subset of options (e.g. not supporting the property case)).

Anyway, while with a lot of limitations some simple cases could be maybe done, it is a ton of work for the cases that are simple to solve in the first place.

#### Pascal

• Hero Member
• Posts: 852
##### Re: Can't we get rid off circular unit reference?
« Reply #19 on: February 12, 2018, 02:37:59 pm »
Yes, but this is another issue. I unfortunately do not see what this has to do with my topic?

Your title is more generic (all types) than the discussion (reference class types only, later limited also to a subset of options (e.g. not supporting the property case)).

Well, yes.

Anyway, while with a lot of limitations some simple cases could be maybe done, it is a ton of work for the cases that are simple to solve in the first place.

If you or someone else could lead me to the relevant places in the compiler/parser sources i will give it a try.
And as asked earlier: Is there an up to date wiki/doku of the inner structure/working of the compiler, which could help me understand the sources?
laz trunk - fpc trunk 32bit - Windows 10 Pro x64 (1909)

• Hero Member
• Posts: 9400
##### Re: Can't we get rid off circular unit reference?
« Reply #20 on: February 12, 2018, 03:09:12 pm »
If you or someone else could lead me to the relevant places in the compiler/parser sources i will give it a try.
And as asked earlier: Is there an up to date wiki/doku of the inner structure/working of the compiler, which could help me understand the sources?
Well, there is "advanced documentation" in the sense that it is documented how the compiler itself can be compiled with debug info. So you can debug the compiler under fpc itself. So you can get any information you want following program flow.
The compiler sources are current documentation, I guess. (Not very helpful, but that's how I do it)
also related to equus asinus.

#### marcov

• Global Moderator
• Hero Member
• Posts: 7804
##### Re: Can't we get rid off circular unit reference?
« Reply #21 on: February 12, 2018, 03:47:09 pm »
If you or someone else could lead me to the relevant places in the compiler/parser sources i will give it a try.
And as asked earlier: Is there an up to date wiki/doku of the inner structure/working of the compiler, which could help me understand the sources?

No, there is not much internal documentation. There are maybe some docs on specific features in the wiki, but the only attempt at all-encompassing documentation is pre 2005, and terribly old. (and even then it is more a guide to look up specific types/nodes, and less a "how to" manual).

So getting your feet wet by trying (bugfixing and simple features) is the typical way to go.

#### Pascal

• Hero Member
• Posts: 852
##### Re: Can't we get rid off circular unit reference?
« Reply #22 on: February 13, 2018, 07:57:24 am »
Okay, then let's start diving in
laz trunk - fpc trunk 32bit - Windows 10 Pro x64 (1909)

#### PascalDragon

• Hero Member
• Posts: 855
• Compiler Developer
##### Re: Can't we get rid off circular unit reference?
« Reply #23 on: February 17, 2018, 07:16:09 pm »
If you want to play around you can try to use the attached patch (might result in conflicts cause it's a bit older already) to play around with the concept of formal classes (like they are done for the objcclass). It basically allows you to use the following code:

Code: Pascal  [Select]
1. unit foo;
2.
3. {\$mode objfpc}
4.
5. type
6.   TFromOtherUnit = class external; // originally declared in OtherUnit
7.
8.   TMyType = class
9.     fField: TFromOtherUnit;
10.     constructor Create;
11.   end;
12.
13. implementation
14.
15. uses
16.   OtherUnit;
17.
18. constructor TMyType.Create;
19. begin
20.   fField := TFromOtherUnit.Create;
21. end;
22.
23. begin
24. end.
25.

Please note that this has the restrictions that you can't inherit from an externally declared class or use fields or properties unless the declaring unit is in scope. It's essentially an opaque reference, because the compiler knows that classes are pointers it can treat it as such for quite some time.
There might also be unresolved problems regarding the RTTI and such which is why I haven't integrated this in trunk.

Trying to rework the unit loading so that circular references are supported is highly discouraged as this can lead to hard to solve bugs (as the introduction of inlining some years back has shown).