[fpc-pascal] Ideas for namespace implementation
pascaldragon at googlemail.com
Mon Jul 26 11:18:11 CEST 2010
Am 26.07.2010 10:40, schrieb Graeme Geldenhuys:
> Op 2010-07-26 10:14, Sven Barth het geskryf:
>> Regarding your ideas 2 and 3: as they are not Delphi compatible they
>> might be considered a "bad thing" (TM) by the FPC developers.
> Currently FPC developers do not want to implement the "dotted" namespace
> idea from Delphi - though they already stated there stance on Delphi
> compatibly regarding this. In short - Delphi in-compatibility is not a
> problem here, just like Generics or Compiler Modes or ..... FPC doesn't do
> everything like Delphi, sometimes it does things _better_ than Delphi. FPC
> Namespaces would hopefully fall under the latter.
I hope this, too. And personally I am not interested in Delphi
compatibility because I only use Delphi (6) at work and there we use a
stable set of compatible components. And the few times I used units from
FPC to achieve something (TProcess, SQLite interface unit) I was able to
adjust them to the Delphi compiler.
>> The problems of all three (or maybe all namespace ideas) is that they
>> aren't compatible to older versions of Delphi (and FPC).
> I don't see this as a problem at all.
> * Currently they have unit name conflicts. No solution other than
> renaming the offending unit. Even if they introduced the "dotted"
> namespace idea from Delphi, it is not supported by FPC, so you
> still sit with a problem. You are forced to rename the unit. See
> the RxLib example.
> * Simply upgrade your FPC to a newer version. FPC is FREE. You don't
> have the burden of Delphi upgrade costs. FPC development is open,
> so you can prepare your code as you see things change in FPC, so
> that when a new version comes out, you already are compatible with
> it (again unlike Delphi - remember Unicode support in Delphi. Users
> had no warning of its syntax and required changes until AFTER Delphi
> was released.).
Yes, FPC is free and examples where an older version of FPC is needed
can only be constructed artificially, but the Delphi case still holds.
E.g. tiOPF supports Delphi besides FPC.
I don't know the unit structure of tiOPF but suppose you have a unit
"utils" that once conflicted with a Delphi unit and was renamed to eg.
Now FPC introduces the new namespace system and you'd like to jump the
train and make tiopf "namespace aware". Now you rename the "tioutils"
unit again to "utils" and set the prefix to "tiopf". Now you've upset
the Delphi users in two different ways:
1) They need to change their uses clauses
2) Now the unit conflicts again with a Delphi provided "utils" unit
(does Delphi have a "utils" unit? it's an example after all...)
Or would you keep the "tioutils" unit name and just introduce the
namespace? But what did you gain then?
So... what is your suggestion for such packages providers to solve the
Please note again: I'm not against this "unit Foo namespace Bar" idea
and the more I think about it the more I like it, but I also tend to see
problems that arise because of such a feature and to discuss solutions
for such problems.
>> Regarding your idea 3:
>> As FPC can use different directories for the search paths how would you
>> solve similar hierarchies?
> Idea 3 is crap - I see lots of issues too, but thought I would mention it
> simply because that is what JAVA uses.
I didn't want to say it that directly ^^
More information about the fpc-pascal