[fpc-devel] Purpose of "uses ... in"?

[Marcos Douglas]

On Wed, Jul 14, 2010 at 2:21 PM, Marco van de Voort <marcov at 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 <marcov at 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.