Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
Then the John Douglas and Douglas McKey are running into the same issue. Both guys (while living on different parts of the world) created the same "douglas" namespace! That's why most languages use domains as namespace Then you would have net.delfire.douglas.* org.msegui.* and no collision On 10/29/2013 02:48 AM, Dmitry Boyarintsev wrote: On Mon, Oct 28, 2013 at 9:27 AM, Graeme Geldenhuys mailto:gra...@geldenhuys.co.uk>> wrote: I would have thought that is exactly what namespaces will be handy for! Or at least a popular use-case. Macros Douglas could define a "douglas" namespace, and the MSEide+MSEgui project could define a "msegui" namespace. Units, Classes or even lines of code should be able to say which namespace they are referring too. Then the John Douglas and Douglas McKey are running into the same issue. Both guys (while living on different parts of the world) created the same "douglas" namespace! Similar to using the same "M" prefix for classes unit. What option do these three guys would have now? Elevate another the level of name space? john.douglas macros.douglas mckey.douglas douglas.mckey? Is it much different than just extending the prefix "M" to "MFP"? thanks, Dmitry P.S. Offtopic: I personally find it horrible to call a unit "classes" (it's fine for RTL, since it's started this way, but any other library - it is horrible). Nobody calls their units like "functions" or "functionsandprodures" (though I think I saw unit "funcs" one day), It is better to give more accurate name of the unit functionality: StrLists, UnicodeUtils, FileUtls, DateUtils. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
In our previous episode, Benito van der Zander said: > > Then the John Douglas and Douglas McKey are running into the same issue. > > Both guys (while living on different parts of the world) created the > > same "douglas" namespace! > > That's why most languages use domains as namespace > Then you would have > > net.delfire.douglas.* > org.msegui.* If you start to use short class names (by importing with *), the ambiguity is back again. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
On Sun, Nov 3, 2013 at 12:06 AM, Dmitry Boyarintsev wrote: > On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote: >> >> On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev >> wrote: >> > >> > On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote: >> >> This works only if you don't want use StrUtils of your project and, >> IMHO, this is more complex solution. You will need to tell the >> compiler which unit of your project that compiles using an unit in >> another place that uses the same unit name you already uses in your >> project. > > Not each unit. The search priority can be adjusted for a directory (3d party > library) > >> >> The "rules" that I proposed are: >> 1- Sources in the same directory and/or own tree are compiled using >> the "real names" of units. >> 2- Sources in another tree are (optional) compiled using an "alias". >> These alias are used as a prefix to real names of units. > > I guess, you need to define "in the same" directory. Is it "the same" to a > project or to a unit? > If to "a unit" then it breaks the compiler backward compatibility. Wrong. Do not breaks the compiler backward compatibility. I said " in the same directory and/or own tree", ie, in the same directory and subdirectories. For these cases, the compiler do not need changes. > So, how to handle the following case? > > /program/unit1.pas (uses TheLib.StrUtils) > /program/unit2.pas (uses StrUtils from program) > /program/StrUtils.pas > /lib/StrUtils.pas > /otherlib/otherlibunit.pas (depends on "lib" StrUtils) > > So how would you "otherlibunit" to be using TheLib.StrUtils? From what I can > understand (following rule #2), you need to modify "otherlibunit.pas" and > change "uses StrUtils" to "uses TheLib.StrUtils" First, if you have a lib that have dependencies to another lib, you have to provide all sources together -- in the same directory or subdirectories. For this case just use the rule #1. But, if you did not provide the sources for the other lib, the user will need to define the "ALIAS" to the lib that have dependencies before compile it (package). For this case use the rule #2. Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
On Sun, Nov 3, 2013 at 1:25 PM, Marco van de Voort wrote: > In our previous episode, Benito van der Zander said: >> > Then the John Douglas and Douglas McKey are running into the same issue. >> > Both guys (while living on different parts of the world) created the >> > same "douglas" namespace! >> >> That's why most languages use domains as namespace >> Then you would have >> >> net.delfire.douglas.* >> org.msegui.* > > If you start to use short class names (by importing with *), the ambiguity is > back > again. Exactly. In Java, eg, if you have two imports with "*" and the two "packages" have the same class name, the compiler do not allow you declare only class name for a variable... "duplicity of names". Because this we see many sources (Java) that for a simple variable the programmer uses the full name (package and class name). If we have "dynamic namespaces" in Pascal, we can use a big name for units (like a big path for a Java's package) but to use simple names on the code. Best regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas wrote: > Wrong. Do not breaks the compiler backward compatibility. > I said " in the same directory and/or own tree", ie, in the same > directory and subdirectories. For these cases, the compiler do not > need changes. > The compiler doesn't use a unit's same directory for searching units. It is using project's file directory for searching and then any directories referenced is -Fu switch. Thus the same list of search directories is used for any unit in the project (and that's causing the requirement to have all unit names unique per project) First, if you have a lib that have dependencies to another lib, you > have to provide all sources together -- in the same directory or > subdirectories. For this case just use the rule #1. > But, if you did not provide the sources for the other lib, the user > will need to define the "ALIAS" to the lib that have dependencies > before compile it (package). For this case use the rule #2. > Changing the structure of a project is a big NO. For a number of reasons: * a compiler change should never force a developer to make any major changes in the project sources or structure; * it might be impossible to merge two different components into the same directory or sub directory, because of the conflicting file names; * the external tools (i.e. SVN) might require two components be in a separate folders (i.e. for syncing sources); -so I'd removing rule #1 as a solution here. As well as rule #2, since it's not an option to change 3d party code (even just to introduce an alias reference). Don't forget that you've mentioned it earlier yourself. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] MorphOS
I just happened across your group while scanning the internet for topics related to my interests. I used to use Pascal uner Microware OS-9 on the Tandy Color computer and I currently use MorphOS. As to the latter, I noticed that free Pascal is listed as supporting MorphOS, but I can not find a download for that OS. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
