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

[John Stoneham]

On Jan 22, 2008 2:48 AM, Marco van de Voort <marcov at stack.nl> wrote:
> [snip]
> ... an import of complexnumbers in one place might suddenly react
> differently due to the partial module/classhelper)

Then you misunderstand the concept. While it's true that child
packages are similar to nested packages (and can be written that way
if you want), if they are written as a separate compilation unit the
parent package is unaffected, and that also includes code which
imports the parent package. The child package is *not* imported when
the parent package is imported, unless it is specifically written as a
nested package within the parent source. Code which imports the
parent, "ComplexNumbers" in this example, does not get the added
functionality of "ComplexNumbers.Polar". There is no chance that code
importing the original package would "suddenly react differently" just
because the child package exists. In order to expose code to the child
package, you have to specifically import it.

Again, it is very similar to inheritance. When using a TShape class,
you don't worry about whether the extended functionality in TSquare or
TCircle is somehow going to affect your own code, unless you
specifically use those classes.

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

No it doesn't. Unless you specifically "use Parent.Child;" the
compiler doesn't have to go looking for "Child" at all, it doesn't
have to factor in the possibility of whether Child exists or not, just
as when you use a "Shape" unit it doesn't have to wonder whether there
is also a "Square" or "Circle" unit somewhere, unless they are
imported. If you only "use Parent;" the compiler won't even compile
the "Parent.Child" unit, even if it exists in the same working
directory.