Forum > FPC development
Can't we get rid off circular unit reference?
Pascal:
I like (free)pascal very much. But one of the most anoying things is the limitations due to circular unit references.
Why do we still need this? Inside a unit we can have foward declaration which can be used to
make two classes to reference each other. Why can't this work accross units? The compiler can stop iterating thru the
units when he raches a unit he has already paresed and behave like he does with forward declarations?
I do not see the reason for this limitation! Maybe someone can give me a clue?
I know that i can use base classes but i have to cast the the base classes to the real classes in the implematation section
anyway.
marcov:
--- Quote from: Pascal on February 11, 2018, 12:22:21 pm ---I like (free)pascal very much. But one of the most anoying things is the limitations due to circular unit references.
Why do we still need this? Inside a unit we can have foward declaration which can be used to
make two classes to reference each other. Why can't this work accross units? The compiler can stop iterating thru the
units when he raches a unit he has already paresed and behave like he does with forward declarations?
--- End quote ---
The advantage of this way is that you only import something that is fairly completely defined (except a few things like inline, and changing of procedure attributes in the implementation). You never have to assume what an identifier means (and backtrack if wrong when you parse the other source) of have workarounds or assumptions in the language to disambiguate this. (and think not just of work to compile correct code, but also the effort to get clear and correct error messages)
And I never saw it as a problem to begin with. I like a nice tight declaration without code in it (C++ and Java classes look messy to me, I can live with it, but consider it suboptimal), and ordering the uses clauses quickly becomes a second nature. I only hit the limit when I'm deliberately experimenting during refactoring rarely or never during normal coding.
Anyway, once you start down a road, regardless what other languages do, you are stuck to that model, or totally redesign and rewrite the way multiple sources are combined to one program, which is one of the hardest part of the program.
Exploring what works and what not, would be more a job for a new and small and focussed pascal compiler that can move more agilely than a twenty+ year old behemoth like Free Pascal with a zillion features that might need fixing and rethinking.
--- Quote ---I know that i can use base classes but i have to cast the the base classes to the real classes in the implematation section
anyway.
--- End quote ---
Generics alleviate that somewhat. I was quite happy how my own container classes ported to it.
Thaddy:
Note that iso mode has iirc such a feature to a certain extend. But only with all iso code. Can't mix it.
[edit] Ahh, I see, not implemented yet, since it is extended mode.
Pascal:
--- Quote from: marcov on February 11, 2018, 01:07:23 pm ---The advantage of this way is that you only import something that is fairly completely defined (except a few things like inline, and changing of procedure attributes in the implementation). You never have to assume what an identifier means (and backtrack if wrong when you parse the other source) of have workarounds or assumptions in the language to disambiguate this. (and think not just of work to compile correct code, but also the effort to get clear and correct error messages)
--- End quote ---
But it stays completely defined. It's just that two classes from two units can reference each other. Like it can be done with implicit forward declarations inside a unit allready.
--- Quote from: marcov on February 11, 2018, 01:07:23 pm ---And I never saw it as a problem to begin with. I like a nice tight declaration without code in it (C++ and Java classes look messy to me, I can live with it, but consider it suboptimal), and ordering the uses clauses quickly becomes a second nature. I only hit the limit when I'm deliberately experimenting during refactoring rarely or never during normal coding.
--- End quote ---
To have two classes reference each other you have to put them in one unit which breaks the concept of clean and simple units.
Or you have to user base classes which makes you use casts in the implementation part which breaks the concept of type safety.
Or you use helper classes.
So why not do it in a straightforward and simple way and enable circular unit references?
--- Quote from: marcov on February 11, 2018, 01:07:23 pm ---Anyway, once you start down a road, regardless what other languages do, you are stuck to that model, or totally redesign and rewrite the way multiple sources are combined to one program, which is one of the hardest part of the program.
--- End quote ---
Yes, but this inconvenience always forces you to find some way around the "circular unit reference problem". So you always have to build some kind of hack!
Imho this is contradictory to the clean concept of the pascal language.
--- Quote from: marcov on February 11, 2018, 01:07:23 pm ---Exploring what works and what not, would be more a job for a new and small and focussed pascal compiler that can move more agilely than a twenty+ year old behemoth like Free Pascal with a zillion features that might need fixing and rethinking.
--- End quote ---
Shouldn't this be quite easy to implement? The compiler just has to stop parsing a unit that he already knows. So unit A can use classes of unit B and vice versa.
Thaddy:
Note for allowing interface sections with multiple implementation sections we already have inc files.
The multi-platform support is even built on that.
Personally
- I can live with how it is now.
- I use include files when appropriate.
- If you have many circular references on the same platform your architecture is probably wrong and we can probably set you on a better track when we see some code..
Problem solved.
Navigation
[0] Message Index
[#] Next page