[fpc-pascal] Ideas for namespace implementation
fpc at mfriebe.de
Tue Jul 27 16:10:08 CEST 2010
On 27/07/2010 14:28, "Vinzent Höfler" wrote:
> Marcos Douglas<md at delfire.net>:
>> You right about "constants.pas".
>> Then I would like to give other example: StrUtils.pas
>> What we expect in unit StrUtils or "Strings Utilities". Is very clear.
>> But we can't use this name. That is the problem (no for FPC's units
>> because we all know their names).
> So we can't use it because somebody already written it for us? So why do you want to write it again? Just kidding. (Well, if it were Ada you /could/ create a child package of StrUtils and add your very own subroutines to the original package, but FPC isn't Ada.)
> Back to your two StrUtils... Now you do what? Invent a "MyStr" namespace to put your own "StrUtils" into it? And if somebody already did that with his very own version of StrUtils? You rename your namespace again?
Ok, in this case Graeme (sorry Graeme) is wrong to blame FPC for taking
the Name => We all should thank FPC for taking it => it prevents
everyone else from taking it, and reduce the amount of very likely
> See my point? Actually, name clashes will occur every now and when. There is *no* way around it unless you start the whole Java-crap with unique domain name prefixes and even that is not 100% bullet-proof.
see the UUID idea (admittedly a bit over engineered...)
> IMO, if there is no further concept of child units (maybe similar to Ada) there is no point in adding namespaces to FPC, it's not worth the trouble. After all, it's still a name and if somebody else already uses it, you still need another to disambiguate.
Yes, Namespaces (those on top of units) will inherit the same conflict
problem that units have. That is as long as the inherit the same source...
That means, if the namespace for a unit is given to that unit by the
writer of that unit, then 2 writers of 2 units will eventually give the
same namespace to equally named units....
*if*, but what is if not. What is if the namespace is not set by the
writer of the unit, but instead of that by the user of the unit.
The user will always know if 2 units do conflict => so he can then set a
namespaces => and because the user (as in the writer of the final
program) knows already all the names, and decides all the namespaces
himself => there will be no conflict.
that can be done by giving the namespace to an include path -Fu / -FU
(if necessary recursive)
=> only draw back, you have to do it equally for every PC /installation
that you use....
(unless the UUID thing....)
Then again, it is only worth the bother, if someone actually deems it
worth his/her time to implement it....
More information about the fpc-pascal