On Wed, Jul 14, 2010 at 2:21 PM, Marco van de Voort <mar...@stack.nl> wrote: > In our previous episode, Marcos Douglas said: >> > And if they want to keep it, then I can not use both Dialogs units. I >> > had not yet the case where I needed both and can not rename both. >> >> Then, another example: >> You want to work with ZIP and RAR format files. So, imagine you found, >> on the net, 2 libs, one for each type format. The problem is each lib >> uses the same name to main unit e.g. zip.pas. >> >> Both libs are very used by million of people on the world and they, >> the developers do not want to change the name of yours unit. > > I would say thats is a pretty strange situation, since those million people > will all have the same problem...
Remember, this is an example... > ... and won't like adding xxx in 'yyy' to all > uses, and edit one of those packages to fix that everytime a new release > comes out. Exactly! On Wed, Jul 14, 2010 at 2:27 PM, Marco van de Voort <mar...@stack.nl> wrote: > In our previous episode, Marcos Douglas said: >> >> And now, you understood the little problem? >> > >> > Of course I understand the problem, but I have not yet encountered >> > it in a real project. >> >> So, if we can to put an alias to unit names, there are no more problem. >> I had this problem in real projects. Always happen with the units that >> have very short names or names that are very generic. Therefore, most >> of the frameworks put a prefix in the units. > > Note that the " in" syntax is not a cure all similar to prefixing and making > sure that that all filenames are unique. This because there are still two > units with the same name in the searchpath, and one mistake in fixing the > uses clauses will cause problems. You're right :( And if we can do that: uses zip IN '/units/my/zip.pas' AS myzip; zip IN '/units/lib/zip/zip.pas' AS ziplib; Now, I can point the real path and I can use 'n' units with the same name. What do you think about it? > Moreover, I agree mostly with Mattias in that dealing quickly with rare > cases is a lot less work then heavy handed approaches to 'fix' the problem. Yes, I agree with you. MD. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel