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

[Michael Van Canneyt]

On Sun, 25 Jul 2010, Graeme Geldenhuys wrote:

> On 25 July 2010 16:20, Marco van de Voort <marcov at stack.nl> wrote:
>>
>> I think that chance is overestimated, unless you use very familiar
>> identifiers (like "buttons").
>
> Visual objects are not the only area such conflicts occur. Creating
> your own Container classes, Process controls etc allows for a lot more
> conflicts with FPC. As FCL expands, so do the chances for conflicts.
> I've already refused contributing some code to FCL, simple because I
> want to reduce conflicts at a later date, and the uphill battle with
> changing something that ends up in FPC. So I follow Martin's
> (MSEide&MSEgui) advice - keep your code to yourself and under your
> control. This reduces all kinds of problems later down the line. [sad,
> but true]
>
>
>> Typenames are less of a problem, since unit qualification can work around
>> them.
>
> No wouldn't it be nice to apply the same idea to unit name problems -
> apply domain qualification to get around unit name conflicts.

What unit name conflicts ? In 15 years that I work with Delphi and FPC, 
and I have use many many packages, I encountered exactly 1 conflict:
the strutils of rxlib, which conflicted with strutils introduced in a later
version of Delphi. The RX copy was renamed to rxstrutils, and that was it.
If the Rx people had named their unit rxstrutils from the beginning (they
did it with all their other units) there would not have been a problem.

I am sorry, but I think that the seriousness of the problem is very much
overestimated. Wanting to type rx.strutils versus rxstrutils. Really ?

And let us not forget: most component vendors must support older versions of
Delphi, so they are barred from using the dotted unit name syntax anyway.

>
> The RTL is not so much a problem, thanks to the long history of
> Borland Delphi - so most developers know what is in the RTL. Now FPC's
> FCL is a great idea, but the more FCL expands, the more changes there
> are for conflicts. But I guess dismissing the problem by you, must be
> acceptable by all (NOT).

Most new FCL code gets fp prefixed to unit or type names, so it's not really
a problem either. We are aware that we should try to avoid conflicts.
It's not like we're looking for them.

I think there are far more important problems than this. e.g. 
the unicode string type. That is a major challenge, with 
significantly more impact on usability.

It would be far better to spend efforts on that.

Michael.