On 25 July 2010 16:20, Marco van de Voort <[email protected]> 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/ _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
