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

[Vinzent Hoefler]

On Tuesday 22 January 2008 09:48, Marco van de Voort wrote:

> 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.


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.

> 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. 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.

> 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"). It seems like a concept to both avoid the classic 
multiple inheritance problems and the issues with interfaces 
implementation.

Maybe I got that totally wrong, but the name implies that I can't use 
a "partial class" in real world code, because it's, well, partial.

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.

> 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.

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, ...

> (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). Or what's with that "reuse" keywords 
for the uses clause?

> 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. ;)


Vinzent.