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

[Graeme Geldenhuys]

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.


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

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. So then you
take option two, implement everything yourself, but now you stand a
chance of getting conflicts as FPC grows. FPC don't give a crap about
other projects (other than Lazarus), so other projects must just
inconvenience their users, by renaming units or classes. A loose,
loose situation for us. Having a language feature to accommodate other
projects would be nice - after all, most other languages have accepted
the chance of conflicting ideas (unit names, class names, etc) and
introduced namespace support in the language.


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


> And moreover, not all editors generate unique UIDs either.

Well, all GUID/UUID generating code I have seen, use the Windows,
Linux Kernel, etc API - so if the editor doesn't tap into that, it is
their problem, no ours or FPC's.


-- 
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/