[fpc-devel] is that intended? private type section in classes versus visibility

[Martin]

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...

fpgui.buttons
fpgui_buttons
FpguiButtons
....


>   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.