On Mon, Oct 28, 2013 at 9:10 AM, Dmitry Boyarintsev <skalogryz.li...@gmail.com> wrote: > On Sun, Oct 27, 2013 at 12:07 PM, Marcos Douglas <m...@delfire.net> wrote: >> >> Yes and how I still use D7 at work I still have this problem. >> This problem happen not only for unit names but component names too. I >> can not register two components with the same name. >> So, because that, programmers around the world use prefix in class >> names. If the components were registered using 'unit+class_name' and >> when we drop a component on the Form the IDE write the unit name as a >> prefix, this problem not will happen. > > Ah, that's an interesting example.I hardly use the component registry > myself. >> >> >> My more fresh example is: >> I have, for years, many units that have the prefix 'M'. So I have >> MClasses, MCore, MTasks, MSystem, etc. >> Now MSEgui (by Martin Schreiber) introduced a mclasses unit -- your >> own implementation of classes unit -- and I can not use both units in >> the same project. :( > > So was the issue fixed? > I'd suggest to renamed your MClassess to MDgClasses or not to use MSEgui at > all. The best approach here is to rename only 1 collision at a time - at > least this is what I would do. The fix is pretty easy - renaming the file > itself and all uses section of units that are using it. (prevents updating > to D2010 for namespaces)
Ok. But if this problem happen in two third-party codes? How will you fix this? Change the third-party code yourself? > I doubt that Martin would agree to rename his MClasses to MSEClasses, since > more people is using the library (that's my guess). There is a mseclasses already... so, he can't rename to mseclasses. But it was just an example. > Is there a risk of bloating the program by duplicatrd code? It sounds to me > that Martin's and yours MClasses are doing pretty much the same thing. > With Namespaces such code duplication will become very welcomed. > > thanks, > Dmitry Namespaces, IMHO, should allow the user (programmer) to change the path -- or something smarter -- where they can not change third-party library codes. Marcos Douglas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
