On Thu, 24 Jul 2003, Matt Emson wrote:
> > On the contrary. We switched to this exactly because the opposite cannot > > be maintained. 8 years of cross-platform experience. > > See below > > > You can simply make a preprocessor which does that if you find it fun to > do. > > But this doesn't change the unit structure, and gives no advantage in > > maintainability at all. At most the end user finds it easier to read the > > sources. > > Your final line is the reason I mention it in the first place. The include > file system may be lovely for yourselves, but it is a mess imho. I have to > look at 3 files before I find the piece of the source I want to look at, and > even then I have to switch between the Interface and Implementation > includes!!!! *This* is not acceptable or compatible with the way I work. > This is what puts me off using FPC 90% of the time. This and the > inconsistencies of the Unit structure. > > I think the end user would benefit from the 'preprocessed' units at release > time, and the developers would keep whatever grand scheme they desire at > development time. > > Please understand, I do not mean you should change your way of working, just > that the end user should not have to see your messy include file ridden > source. Does that make sense? It does, with the proviso that 'messy' is a very personal appreciation of our file structure. I find it logical and not confusing at all. Keep in mind that it must be cross-platform. Your remarks are focusing on the point of view of a single platform user. For multi-platform development, wading though include files is easier than wading through zillions of IFDEF statements: At least from the name of the include file (displayed by your editor) you know in what part you are working. Not so when working with IFDEFs. > > > I think you'll have a hard time convincing the core members. > > You haven't convinced me. The system as it is works well, it took us > > some time to get it like that, so we're not likely to change it, just > > because someone doesn't like split-up files. > > See above. > > > When I was at borland for an interview, the first thing I asked was > > support in the IDE for include files. They scratched their head, and > > said they would think about it. > > I'm pretty sure that the Unit files that are distributed by Borland are > constructed by a script from a larger source repository. I doubt they work > directly on the source files as we end users see them. I think they do, because the IDE does NOT support include files, so you simply cannot work with include files and enjoy the blessings of the IDE. I was told that for productivity reasons they do all development in the IDE itself, so... > > > This is the main reason why Delphi sources are generally without include > > files: because the IDE doesn't support them. Personally, I find it more > > logical e.g. to have one include file per class, this is simply not > > possible in Delphi. > > The IDE doesn't support them because they make the browsing of code complex > and irritating. The way CBuilder handles Headers and C files is annoying > enough imho. Thankflly Borland do not subject us to the torture FPC does. > > Remeber, just because it's easy to maintain for you, doesn't mean it's a > good thing for the end user. That's a fact I'm afraid. Once more, this is a matter of taste. Michael. _______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
