On Tue, Aug 21, 2012 at 5:19 PM, Marcos Douglas <m...@delfire.net> wrote: > On Tue, Aug 21, 2012 at 4:42 PM, Jorge Aldo G. de F. Junior > <jagf...@gmail.com> wrote: >> 2012/8/21 Marcos Douglas <m...@delfire.net>: >>> On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort <mar...@stack.nl> wrote: >>>> In our previous episode, Marcos Douglas said: >>>> >>>>> I proposed this sintaxe: >>>>> uses my_long_unit_name as my; >>>>> begin >>>>> my.proc(); >>>>> end >>>> >>>> This doesn't protect any better, since >>>> the new unit might also define "my". >>> >>> True, but using this sintaxe I can use an alias to the third-party >>> units so, I can use my own names to reference identifiers that I can >>> not change. >>> The collision still can exists? Yes, but in that case the programmer >>> would be wrong, not third-party unit names or because the compiler not >>> helped. >>> >>> The third-party could use a better and bigger name like "XyzNetSocket" >>> but I could use just "net" (uses XyzNetSocket as net), for example. >>> >>> IMHO this is more sophisticated than pure namespace. >> >> Instead of implementing the half-assed C++ namespace model, just add >> to the compiler a warning when it detects that there is a collision in >> the current scope (two functions with the same parameters from >> different units that can be called from the scope being inspected). I >> believe function overload alread provides the necessary hooks, but i >> cant do it because i have zero experience with FPC sources... > > Well, a good idea but this is another thing... > This is do not resolves the problem if I have a third-party unit with > the same name that other.
...continue: If I can use an alias to ref an unit, the names could be bigger because I can ref them only using the alias. Extend the concept: if nevertheless we have same names in two libs (eg: foounit), we could use: uses foounit as f1 in '/path_1/foounit.pas', foounit as f2 in '/path_2/foounit.pas'; IMHO, would be PERFECT. Marcos Douglas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
