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

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > 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.

If you use such relatively short and frequently used names, there is a
chance. Of course it is a chance over years, and you don't have to take the
simplest of names. A prefix is one "solution", but I prefer a bit longer
names.

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

Keep in mind that cooperation must come from both sides....
 
> > 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.

Kiss of death phrase again. And no, that is no solution, at least not
differently than using domain_unitname. Since the different levels have no
other meaning, unless you go in the directions of classpath, and change the
whole usage and philosophy of how the compiler searches files. 
 
> > You can get used to live with only one leg yet. But I don't plan to start
> > sawing because of that. Getting used to it is not a reason.
> 
> Doing nothing is also no excuse.

I think so. A minor problem does not always warrant a solution.

Of course, there is more drama to fix such non issues "because we have to do
SOMETHING", but IMHO it is much ado about nothing. Worse, non of the
solutions are really solutions, or (like in the case of namespaces) not even
properly described (designed?) enough to comment on.

I'm a bit careful of namespaces because there are known solutions about how
compilers find files (Java, C#), but the practical merger with the Pascal
unit system would have to be very carefully described.

Worse, the pascal unit system's inner workings and philosophy would have to be properly
described first :-)
 
> > I think the problem is blown up out of proportion, and the remedies
> > draconical. But if you disagree, just use long unit names.
> 
> 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).

No. The problem is real. I just don't think the solutions proposed solve the
problem more than simply picking less likely names. (which you could see as
a solution either).

Keep in mind that I have seen all those conflicts, and mostly were one word
names which were very common. THAT's the mistake. People picking such names
set themselves up for failure. (just like when they would use such common
names for namespaces later on)

> I see this as a loose/loose situation. First I tried to use everything
> FPC has to offer - why reinvent the wheel. But then when you find
> problems - solution are not accepted by FPC, or the core team makes it
> so hard for you, you just stop caring or contributing.

Yeah, yeah, we all know your rants. Most people can cooperate with core
fine, but you can't. And of course that is the problem of core. 

> > Because if I think if a 3 letter prefix is draconical and unreadable, guess
> > what my opinion about the userfriendlyness of GUID's is. GUIDs are for
> > meant internal details, not for anything routinely handled by people.
> 
> My idea was meant to be similar to how interfaces are handled. You
> declare a GUID when you declare a Interface, but you hardly every have
> to type that GUID anywhere.

> The language takes care of that for you.

> So I was suggesting something similar for unit names. I didn't say it
> will work, or defined all implementation details - just throwing an
> idea out there, that could possibly spark some solution. You being
> super negative to anything is no surprise to me either - what was I
> thinking.

This is exactly the problem I describe above. Ideas are barely fleshed out,
and yet you already dig in. 

If your idea was really so great, and this was really a solution, why don't
you simply describe it?

Details are important. Fix a few bugs, and be bitten by them a few times....