[fpc-pascal] child units (was: dot within unit file name)

[Marco van de Voort]

> On Monday 21 January 2008 18:45, Marco van de Voort wrote:

> > I have missed opague types and forcedly qualified importing  (from
> > M2)
> 
> Well, I miss them too. As I'll show you in a moment that they even go 
> hand in hand with child packages.
 
> > M2 doesn't have the nested module "put in arbitrary other file"
> > system though. Such system would have the same problems with M2 as
> > with Pascal.
> 
> Well, you'd definitely need to store not only the information about the 
> interface part in the .ppu file, but also the implementation part, so 
> that any child package can access and use this information.

Then they are different from Modula2. Since in Modula2 you can only process
the inner module as part of the whole module. They are not separately
compilable and are part of the implementation (of course you can inc though)
 
> Because without separate compilation(-units), child packages are 
> relatively useless. After all the real big advantage is that you can 
> extend a package without touching the existing one.

Maybe. Keep in mind that opague is roughly comparable with 

type tmyopaguetype = type pointer;

Since the interface must 100% define the interface so that it can be used,
which is a hard rule with Pascal and Modula2.

This makes e.g. the operator overloading already hard, since it can't be a
record (even variant). 

I think also that it puts a bomb under your example in other ways.

> Now the only ways to add functionality to the unit would be to

 
> No touching of the original "Complex_Numbers", no recompilation for 
> units already using it and the knowledge that the original code has not 
> changed a bit. Additionally the inner working of the type "Complex" is 
> still not exposed to any other unit.
> 
> And yes, I miss that.

It is a bit the .NET class helper (partial classes) trick in a modular
setting. I don't like that either. The gain you get from your old and
trusted code, you loose in complexity and clarity of overview in the module
system (an import of complexnumbers in one place might suddenly react
differently due to the partial module/classhelper)

Not to say that it also hugely complicates the compiler, since it has to
factor the possible existance of these slave units in any unit usage.