On Jan 22, 2008 2:48 AM, Marco van de Voort <[EMAIL PROTECTED]> 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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal