[fpc-devel] is that intended? private type section in classes versus visibility
fpc at mfriebe.de
Sun Jul 25 19:28:59 CEST 2010
On 25/07/2010 18:03, Graeme Geldenhuys wrote:
> On 25 July 2010 18:28, Martin<fpc at mfriebe.de> wrote:
>> to your project forever => so what gurantees it isn't going to happen the
>> same with namespaces ?
> The greatly reduce the changes of a conflict.
And the exact same can be said for longer unit names...
> Namespaces have already
> been proven to work. Just look at Java, .NET (Delphi, C#, etc), C++
> etc. So I don't think it's needed to argue if namespaces work or don't
Namespaces may language dependend have other
properties/functionalities, that may or may not be useful => but that is
*not* part of this discussion => so keep it out
The only other thing, if for example looking at JAVA, and that is
related to *reducing* ( *not* avoiding) conflicts (and that acts exactly
like longer names) is that, for example in Java, due to namespaces, the
llibraries provided by java itself also have longer names, There isn't
just Buttons, there is java.awt.Button
But then again, if that is part of the solution, you do not need to
argue for fpc do have namespace, you need to argue for fpc, to prefix
all the units in the rtl, and fcl (buttons being in lcl).
Because if all fpc units were prefixed with a known prefix, then
anything a=fter this prefix can never affect others => if they are not,
then no namespace, no prefix that you or other use, is ever save from
being suddenly used in fpc.
The problem of conflicts is not missing namespaces.
It is to short names for units in the rtl/fcl / and it is missing
default (known) prefix of all of those units.
More information about the fpc-devel