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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
