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

[Marco van de Voort]

> > 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.
> 
> 
> Hmm, what if
> 
> --- 8< ---
> 
> interface
> 
> type
>    tMyOpaqueType; // Incomplete.
> 
> private
> 
> type
>    // Complete type declaration, but privately.
>    tMyOpaqueType = record ... end;
> 
> --- 8< ---
> 
> would be possible?
 
> The type is still declared in the interface part; yet, because it's in 
> the private part of the interface, no other module can use it's inner 
> structure.

No. Completely defines (most notably its size, probably also its alignment
if it applies). In practice, nearly all M2 compilers only support pointers
 
> > This makes e.g. the operator overloading already hard, since it can't
> > be a record (even variant).
> 
> Well, yes and no. As I wrote, you'd need to store that information in 
> the unit file.

You can't. Sb might already be needing the interface before the
implementation is compiled. This is how interface - implementation uses
circular references are solved.

> And it just implies that the type will always be a reference type, because
> that's about the only way to ensure consistent usage across multiple
> compilation units. Of course, at the low level, this means pointer.

Yes.
 
> > It is a bit the .NET class helper (partial classes) trick in a
> > modular setting.
> 
> From what I understood, those partial classes are different. They don't 
> extend functionality, they split it (or maybe, the call it "delegation 
> of responsibility").

As far as I see it they add functionality to a base container. In partial
classes case a class, and in Ada's case a module.

Both also seem to require to include the relevant "helper" module
explicitely to unlock the extension.

> That's not the case here. Each module provides its very own set of 
> (working) functionality. Of course, any child package depends on its 
> respective parent package, but it's not that you need both to do 
> something useful.

Also not that different, though only to my admitted limited knowledge.
 
> > 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
> 
> Actually I don't understand that part of your argument. Any software 
> system that contains more than a couple of lines of code is complex or 
> is going to be. That's why modularization was invented in the first 
> place: To be able to fight and handle that complexity in some way.

> I mean, I'm quite sure, you're not argueing for an "all source in one 
> large file" approach... so instead of (shared) include files, child 
> package would provide compiler checked extensibility.

I don't like the idea of modules being mutable (even if it only means
extension of the container)
 
> IMO, it's much like the package system for the compiler. At least how 
> it's laid out: You have FCL that consists of FCL.Base, FCL.XML, ...

I don't see any relation. FCL only exists as parts of names and in
documentation. On src level there are only the packages, and they are not
spelled above (where they imply some hierarchic system), but with dashes
that aren't separators.
 
> > (an import of complexnumbers in one place might 
> > suddenly react differently due to the partial module/classhelper)
> 
> But that's the case already. Even the order of imports is semantically 
> relevant (or well, it might be

But does exuse throwing out all restraint?

> Or what's with that "reuse" keywords for the uses clause?

I'm no fan of that. But at least it doesn't require scanning and indexing
all files up front. (though, admitted, neither do child packages, I just fail
to see their use)
 
They do have in common that a use case that would interest me could swing
me. And reuse seems to make some sense in breaking up large header sets,
though I'm not really convinced yet.

> > 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.
> 
> Hmm. I don't see that. If I'd put the implementation all in the 
> interface part, the compiler can handle it well already. The only 
> difference would be some sort of flag that this or that information can 
> only be used if it's a child package...
> Don't get me wrong, I don't want to say that it would be easy to change 
> the compiler to handle this, but I wouldn't say "hugely complicated", 
> neither. It does most of the work already. ;)

(I assumed a child package would be autoloaded into a module that imported
the base package. Apparantly I'm wrong there)