Hi!

So... continuing the thread were it belongs... in fpc-devel :P

The whole idea is to compile units with a namespace not just using on in the uses because it's funny.
Either its compiled by including "namespace Foo" in the units themselves or by using a commandline parameter "-namespace Foo", so that not every unit needs so be changed (both modes are supported and the "in unit" version takes precedence of the commandline one).

It's not about not having to type the "fully qualified name", but about not having to rename/prefix my own units, because they conflict with an existing unit.

Can you explain what you want to achive with that directive, please? Currently I don't get that... :(

Regards,
Sven

I said here:

If you impose the namespace, the compiler will know if foo.bar.a is a variable, field, namespace, etc.

MD

Ok, so that means:
If refering to the unit, or any element in it, you always have to use the full namespace:
uses my.utils;
var a: my.utils.TFoo;

that is, inside the unit that uses the other unit, the other units name is effectively "my.utils" => with the dot being part of the name

If writing a unit, that is to be in a namespace you can do
   unit utils namespace my;
but that is no different from doing
   unit my.utils;

*** up to this point, there is no difference to using a prefix on the unit name? "unit MyUtils" ***

The new thing is that you are allowed to give the namespace on the commandline, effectively allowing to change it without needing to change all of the sources

But that can be done for prefixes too:
fpc -unitprefix=My Utils.pas

It acts like a pre-processor, it will find the unit declaration, and prefix the unit name...

So no fancy-new and introducing-problems (ambiguity mu.utils.a => unit my; record utils) issue....

--------------
In fact if the existing
uses Foo in 'dir';

could be extended to allow a package or similar
uses Foo in 'LCL'

and an alias directive would be introduced, then it was all solved too

uses Foo in 'lcl' alias 'FooLCL', Foo in 'RTL' alias 'FooRTL'

Replying to myself..

Using Aliases for unit names could be an alternative, that solves the problem (conflicting unit names can be given different aliases)

And it would not require any new prefixes in the source or anything. no new meaning of a dot, separating namespace and unit name....

uses MyLongAndUniquePrefixedUtils alias 'utils';
// from here on the compile knows the unit as utils and utils only [1]
...
begin
   utils.Foo;

----
[1]
it is to the implementer not top use common rtl unit names such as strutils or sysutils as alias => as it obfuscates code ----

There is only one name by which the unit is known, and it follows exactly the existing rules.

The alias of course will be enforced to be unique within this uses clause (or all uses clauses of this unit)
You can not do

   uses Foo, Bar alias 'Foo';  // error

-----------
As for the problem wich unit Utils to use:

If every search path could have an optional alias
eg for the rtl units, the alias was RTL
Lazarus could define LCL for LCL stuff.

any other package could define an alias for their path => the alis could be on the commandline, or in the fpc.cfg => it will be given to fpc the same way as the search path itself.

Then the "in" clause could be made to accept such aliases

uses Buttons in 'LCL';
and with alias
uses Buttons in 'LCL' alias 'LclButtons';

Not exactly, because

1)

"unit utils namespace my" resides in "utils.pas"

while

"unit my.utils" resides in "my.utils.pas" (Delphi compatible).

(no usage of compiler switch -Un here)

2)

You can still do a

uses
   utils;

with the namespace approach. The namespace-identifier is only needed if you want/need to avoid a conflict.

In theory, yes, but Delphi allows more than one prefix for the unit name (see
http://docwiki.embarcadero.com/RADStudio/en/Using_Namespaces_with_Delphi ). Except you regard the complete sequence up to the last point in the unit name as prefix... but it's still not exactly the same because of the reasons mentioned above.

It acts like a pre-processor, it will find the unit declaration, and prefix the unit name...

Not really. The namespace will be saved in the ppu as an extra field in both usages (in unit vs command line). So you can still use "utils" without the "my"-Prefix/Namespace (see above).

That would be another possibilty (and might be added as an alternate idea to this discussion ^^), but currently this "in"-syntax is restricted to the "program"/"library" file.

Regards,
Sven

That is a question of who the compiler is implemented to interpret this. "unit my.utils" could well reside in utils.pas

Now we are going in circles....

that is the whole point I have been making for several males.

The use of not fully qualified unit names is pure evil => it leads to mis interpretion by the reader.

Telling the implementor, that he can use "sysutils" as unit name, will lead to the implementor doing eaxtly this => and the reader will be confused

Martin

And when is a unit considered as part of "LCL" and when as part of "FCL"?

Can you write example command lines and units for such a system, please?

Regards,
Sven

-Fu=/path/to/lcl // already existent, unit search path -Fa-LCL:/path/to/lcl // define the LCL alias

uses Buttons in 'LCL'; searches in the given search path, and only there

Martin

You're right... it could be defined like that as well.

Eh... right... there was something... shame on me.

Regards,
Sven

Martin wrote

-Fu=/path/to/lcl // already existent, unit search path -Fa-LCL:/path/to/lcl // define the LCL alias

should have been an = sign
-Fa=LCL:/path/to/lcl // define the LCL alias

alias ends at the ":" or whatecer separator is defined.

---------
Thinking about it, there is no need for an extra -Fa (define alias)

-Fu can just be extended

uses Buttons in 'LCL'; searches in the given search path, and only there

I talked about it here:
http://lists.freepascal.org/lists/fpc-devel/2010-July/020699.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020791.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020856.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020934.html

MD

That can be interpreted as following:

The search path becomes the namespace => by defining an alias for a search path
-Fu=LCL::/path/to/lcl
the alias "LCL" has been defined, to include all unist in this search path

using a unit from a anmespace is done with the existing "IN" operator (which needs to be extended to support this, and which needs to be allowed to be used in the scope)

    uses Buttons in 'LCL';

Conflicts in names are solved by aliases. Therefore there never is a need to specify a fully qualified name "LCL.Buttons" (such a name does not exist / can not even be used). Instead the alias is used.

all solved.
No new syntax elements needed (except for alias)

---------
Advantage over namspaces:

Namespaces send the (wrong) message: the developper does no longer need to care about clashes.
that message is wrong, because:
1) one name => many units => unreadable
2) while unitname clashes can be solved => namespace-name clashes can not be solved
That message also leads to using names that are more likely to clash, resulting in more clashes, that require more fully qualified names....

using IN and ALIAS,
- the developper should still attempt to use names that he hopes to be unique: MyFooStrUtils,instead of StrUtils
- only in the rare case of a conflict, action is needed

Martin

IMHO, to work also in Delphi, just in 'delphi mode'...

MD.

Not exactly. Yours is a bit different:

uses
Foo in 'whereever/the/lcl/dir/is' as FooLCL,

   Foo in 'whereever/the/rtl/dir/is' as FooRTL;

The idea of Martin's concept is to define "aliases" for the search paths as well so that you can change them by configuration or command line. So you wouldn't need to check whether your path to the e.g. the LCL is the same as on Martin's computer or mine.

Whether we use "as" or "alias" and a string or an identifier for the unit alias is not that an important topic.

Regards,
Sven

Well... now that I know how you want those "in 'LCL'" things to work I tend to prefer your solution... (I'm easy to convince, I know ^^).

Also it's backwards compatible if it is not used. Nice :D

Regards,
Sven

Okay, but Martin's gave us an example: uses Buttons in 'LCL' ...and if I have a buttons.pas too?

Will be like that?
uses

   buttons in 'LCL', buttons {my buttons};

The classes/functions/etc will be depends what unit was declared for last?

MD

This is cool, but duplicate names may still exist.

MD

This will generate a compiler error, because you can't have two units with the same name in a uses clause (to be exactly: both uses-clauses of an unit). You must use an alias for at least one of them. Maybe it should be defined so that it's only usable with the "in"-directive.

E.g.:

uses
buttons in 'lcl' as lclbuttons,

   buttons;

is valid while the following is not:

uses
buttons in 'lcl',

   buttons as lclbuttons;

Regards,
Sven

Needs to be defined.
What happens, now, if you have Buttons.pas in your project path?

Possibilities:

1) no IN => use current dir / project
2) IN '.' => '.' is a path = the current dir.
In (without alias) works on the directory that is current for fpc => should be the project
3) IN 'PROJECT' / IN '@'
Define a constant alias/symbol for the "current project
4) allow the user to specify a symbol for his project

- With solutions 2,3,4 => a definition is needed for 1 => what is default => should be same as currently
- 2: In '.' => would also always work => same as currentl / current dir
- 3: IMHO not good
- 4: Can always be allowed -FuFOO:. // note the dot as dir => current dir => should be project dir

This is my idea, but better!
In my first idea, we have a problem of PATH names (\=win, /=linux and people prefer to use the search path).

Now, I liked.

MD

True, but they always do:

- Currently you get duplicate unit names
- With namespaces you get duplicate namespace-names
- with search-path aliases, you get duplicate aliases

You can change the search-path alias of any package that yyou use, in the packages settings => that is quick and easy.

Of course that could leave you with 100 of units in your project, that point to the old alias....
Actually NO it could not.
You get the conflict, if you add a new package => so then you change the alias off the package that is new, and not yet referenced.

of course if you add 2 packages, which both rely on the alias FOO, but expect something differnet under foo, ==> but then, you can specify different search-path aliases, for compiling each packages => solved again

And last not least, to reduce the amount of references to the search path aliases => you could use the program file to define glabal unit aliases

programm xxx;
uses FOO in 'LCL' alias 'LCLFOO',  unit1;

---
unit unit1;
uses LCLFOO; the alias from your program

---

maybe a similar "global" file could be used to define a package, and define global aliases for a package.

   Package SynEdit;
   uses....

and to compila all units of the package, you compile th package file (same as the programm for your app)

Martin

I agree, as I said here:
http://lists.freepascal.org/lists/fpc-devel/2010-July/021106.html

MD

I am not sure if this has been proposed, but wouldn't it make life a lot easier if we considered the 'namespaces' metaphor as something that resembles to URLs.

Here is an example:

In the project file, I'd like to have these declarations:

namespace Lazarus readonly url 'C:/Program Files/Lazarus';
namespace FPC readwrite url 'C:/Program Files/FPC';
namespace JCL readwrite url '//MyNAS/Pascal Files/Jedi/JCL';
namespace MeObjects readonly url 'https://code.google.com/somepath';
namespace GreatProject readwrite url
'';

And, in the units themselves, here is what I'd like to see:

uses
   alias Delay namespace Lazarus path 'components\jcf2\Utils\Delay.pas';
   alias Calc namespace FPC path 'trunk\ide\fpcalc.pas';
   alias Serialization namespace JCL path
'source\windows\JclDebugSerialization.pas';
   alias MeConsts namespace MeObjects path 'MeObjects\src\uMeConsts.pas';

which can also be written as:

uses
   alias Delay as lazarus.components.jcf2.utils.delay;
   alias Calc as fpc.trunk.ide.fpcalc;
   alias Serialization as jcl.source.windows.jcldebugserialization;
   alias MeConsts as meobjects.meobjects.src.umeconsts;

[here, the last item in the 'as' path is assumed to have the extension '.pas']

or, without aliases, this way:

uses
   lazarus.components.jcf2.utils.delay;
   fpc.trunk.ide.fpcalc;
   jcl.source.windows.jcldebugserialization;
   meobjects.meobjects.src.umeconsts;

Now, there's the 'path with spaces in it' problem. I think we should solve it the way HTML did.
IOW. let there be %xx characters in the file names and paths [ see http://www.blooberry.com/indexdot/html/topics/urlencoding.htm ]

2010/7/26 Adem :

Please, see that:

http://lists.freepascal.org/lists/fpc-devel/2010-July/020699.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020791.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020856.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020934.html

MD

I had read them at the time.

I wouldn't have much of an issue with something like

uses
  zip IN '/units/my/zip.pas' AS myzip;
  zip IN '/units/lib/zip/zip.pas' AS ziplib;

except that it seems (to me, at least) to declare what we are doing before doing it.

I mean, it might be more pascal-like if we did it like this:

uses
  alias myzip in '/units/my/zip.pas';
  alias ziplib in '/units/lib/zip/zip.pas';

so that, the parser knows -before hand- what is to follow.

But, this handles only the aliasing.

In the above example, the '/units' folder is relative --I assume-- to the project and not relative to an (so to speak) URL, i.e. namespace. Which means, if you moved that folder elsewhere, you'd have to alter each and every place it is aliased.

Obviously, there is no perfect solution to units-moved problems, but if we treated namespcaes as URLs, then we could simply move the whole folder structure of that project somewhere else and only have to reflect that change in one place. I.e. in the project file where 'namespace's are declared.

Anyway, it goes without saying that this is just an idea.

2010/7/27 Adem :

And if you have multiple developers working on the same project and their source code directory hierarchy is not exactly the same as yours (shown above), then that project would not compile on there systems. You cannot hard-code such paths inside a unit and have any hope that it will be "portable" between developers and OSes (\ vs / delimiters).

Thats why,. if you read the following thread:
http://lists.freepascal.org/lists/fpc-devel/2010-July/021088.html

you will see that there is a better solution

For each package, you must specify a search path (commandine or fpc.cfg) -Fu=path

Extend it do declare an alias for the path (which then is your namespace

-Fu=SynEdit::/path/to/symedit

uses Utils in ':SynEdit' alias SynUtils

Yes.

And, it seem you did not read the rest of my post (including the first one with this subject line) :)

I am with Graeme on this one, as in I do not see what you may have written, that solved the above....

To be sure: this mail ?:
http://lists.freepascal.org/lists/fpc-devel/2010-July/021112.html

where does it solve that if I write a unit with this lazarus namespace (my installation)
C:\laz_svn\

will work on a default windows install; not to speak a linux system. The path depends on the system.

If you mean the path, is only a string or placeholder, and does not actually point to the sources (which I can not find in your mail), then how does fpc know the correct path to the source? (I have 4 lazarus instalations, and 3 fpc installations => with different versions => how is fpc going to work that out?

Martin

Let's call that a local URL/URI.

You would make a not of that in a cfg file --either a global one, or per project.

will work on a default windows install; not to speak a linux system. The path depends on the system.

Yes. And, as long as you're working on it on a single machine and not intending to move to another machine, that solution is fine.

But, if any of the above is changed, you would have to setup an exactly the same folder structure elsewhere.

Let's consider a case that is complex yet simple enough to be generalized.

Suppose I have my copy of Lazarus on a different machine (a NAS server) on the local network.

Here is the Samba path to it: '//NAS_Box/Development/SVN/Lazarus/'

IOW, for this local network, this is the URL to 'Lazarus' sources. Lets call it 'lazarus_svn'

Now, suppose I need to access and use the file called 'frFuncNum.pas'

From 'lazarus_svn' this is its' path:
'trunk/components/lazreport/source/addons/addfunction'

Or, in 'namespace' parlance, [please ignore the symbols]

lazarus_svn.trunk.components.lazreport.source.addons.addfunction.frfuncnum.pas

Fine. Now, have path to that file that is unmistakeable.

Up to this point, we have nothing to do with 'alias'es.

Aliases come into play only when we need to refer to something in 'frfuncnum.pas' that might conflict with another on in the 'uses' clause.

Here is what I mean:

Say, you have a function called 'frIsRangeNum' in one of YOUR units which also exists in 'frfuncnum.pas'.

To make sure you're referring to the correct one, you would (otherwise) have to write the following (on a single line, every time)

Result :=
lazarus_svn.trunk.components.lazreport.source.addons.addfunction.frfuncnum.frIsRangeNum();

As we all agree, that's inhumane.

So, you could use an alias for
'lazarus_svn.trunk.components.lazreport.source.addons.addfunction.frfuncnum.pas' and call it, say, 'Laz_svn'.

Once you do that, the above long line becomes such --which is a lot more manageable.

Result := Laz_svn.frIsRangeNum();

Obviously, instead of using 'namespace', you could go straight on and declare the alias as an absolute path to the actual file, but, that would make that code totally unportable.

Side note: As you probably know; Delphi, too, uses a kind of URL. If you look under 'Options' you could see stuff like '$(BDSCOMMONDIR)' or '$(BDS)' etc. And, you can also declare your own, such as '$VCL' to point to your own directory called
'C:\Users\username\AppData\Local\VCL'. Trouble is, they are not definable per project nor are they easily transferable from machine to machine.

Correction:
You would make a NOTE of that in a cfg file --either a global one, or per project.

You mean as in a namespace to path translation?

so I write in my cfg
C:\laz_svn\ = C:\lazarus
?

Then why have the namespace identifiers in the source look like a path on disk at all? Why not all make them symbolic?

It doesn't have to be a single word like in my other mail thread (so I still prefer that) => it could be fpc.core.rtl

Mind if used in "uses foo *in* 'namespace' " => iot's a string, so dot, slash you name it, whatever you like

> will work on a default windows install; not to speak a linux system. > The path depends on the system. Yes. And, as long as you're working on it on a single machine and not intending to move to another machine, that solution is fine.

Wrong, As I said I have 4 diff installations, and I move stuff between them

See my other thread => I never need to make a change, once I set it up => butif the path is in the pascal source, I keep having to change stuff

Can we please think out of the box of how you would fit that in the cfg file for a moment and consider the larger picture?

Yes, in that example, 'laz_svn' would be a central indirection identifier to your 'C:\lazarus'.
But, it could also contain protocol information (such as ftp etc.) to accessing a remote machine.

Then why have the namespace identifiers in the source look like a path on disk at all?

Because it is helpful?

But, of course, you don't have to --as long as you devise a way to get to the path.

Why not all make them symbolic?

How symbolic you want them would be up to you the user.

?

Of course you can. As long as they are identical where it matters.

I can even set up a 20 installations, even with spaces in paths. All I have to do is to map the root folder as another disk with a letter.

Trouble is, when I want to use another machine, I need to do pretty much all of it all over.

See my other thread => I never need to make a change, once I set it up => butif the path is in the pascal source, I keep having to change stuff

If you're so comfortable with that, then why are you interested in aliases?

Just because you have 2 file names conflicting?

You know that it's not an impossible problem, don't you?

You just rename at least them and go on living a peaceful life.

IOW, if you boil everything down to how it immediately helps you and only you, there's little reason to consider alternatives.

In our previous episode, Martin said:

Extend it do declare an alias for the path (which then is your namespace -Fu=SynEdit::/path/to/symedit

: is a legal char on Unix:

[Turtle] </home/marcov> mkdir ::
[Turtle] </home/marcov> ls -lad ::
drwxr-xr-x 2 marcov users 4096 Jul 27 05:23 ::
[Turtle] </home/marcov>

True, just abn example...

2 possibilities:

1) find a char , that is not possible in a path on any system

2) have an option that says "prefixed path" -FUSynEdit:/path the first : is always the separator.

Well because if you read the thread, I specified => and take the above aliasing into account, then the bigger picture is that they are merely the same.

2 differences:

1) mine doesn't have the path in the source => therefore all people on any OS, with any installation can use the same Namespace identifier
- I consider that somehow a big advantage.
- Also if I had to have a path in the source, I woul definetly not want it to be the wrong (even if correctly translated) path => what's the point, other than being completyl misleading and obfuscating?

2) mine is more pascal like. Not so much the difference, how it is specified in the uses clause (even though "in" is an existing operator). But definetly in the following source.
While yours allows for a complet new syntax, referring to a unit with a new namespace.namespace.unit.whatever_in_unit syntax, mine still just has a single valid pascal identifier for each unit.

foo.bar.unit_name isn't really pascal => why do we need t invent a new language, if we can solve it within the existing one?

It is helpfull, if something looking like a path to the file, is wrong pointing to the wrong location for at least half of the developpers working on a project???

sharing source via means like revision control is quite usual. Different OS, different setup is usual too

But, of course, you don't have to --as long as you devise a way to get to the path.

See my other thread
alias for the path: LCL=''loacation of your LCL
the alias is in the same global config (not in the source) as the path is => the config for hte path already exists

uses Buttons in 'LCL'  alias 'YourNameForTheUnit';

> Why not all make them symbolic? How symbolic you want them would be up to you the user.

No => they should be valid pascal identifiers => that means no dot inside

Read
http://lists.freepascal.org/lists/fpc-devel/2010-July/021088.html

and the other msgs in that thread

"diff" = short for different

Do you read what I write?
I write "I have different installations"
You say "Of course I can, as long as they are identical"

afaik "identical" opposite of "different"?

I can even set up a 20 installations, even with spaces in paths. All I have to do is to map the root folder as another disk with a letter.

And that is windows, having drive with letters...
There are only 26 letters for those drives. => I am running out of them. (I've got severla memory sticks, external backup drives, mapped network drives .... each needs a letter)

I didn't ask for them in first. I try only to contribute towards a propper solution

Just because you have 2 file names conflicting?

I don't => ANd I don't need the solution myself neither

Martin

Op 2010-07-27 07:32, Martin het geskryf:

1) find a char , that is not possible in a path on any system

That's going to be rather hard under Linux. Linux (ext2, ext3, ext4, JFS, XFS etc) supports all bytes except for NULL and /. And yes, even none visual chars can be used - in their escaped format. :-)

But yes, you have a good idea. Most IDE's implement IDE Macros to do what you describe, but letting the compiler itself support it, would be very welcome too.

Regards,
- Graeme -

On 2010-07-27 8:49 AM, Martin wrote:Yes, in that example, 'laz_svn' would be a central indirection identifier to your 'C:\lazarus'.

It is helpfull, if something looking like a path to the file, is wrong pointing to the wrong location for at least half of the developpers working on a project???

I give up.

Can't keep writing the same things over and over again.

And that is windows, having drive with letters... There are only 26 letters for those drives. => I am running out of them. (I've got severla memory sticks, external backup drives, mapped network drives .... each needs a letter)

http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx http://www.linkedin.com/answers/technology/information-technology/information-storage/TCH_ITS_IST/566846-13405901

[This mail initially went to Lazarus list by mistake. Sorry about that.]

Martin wrote

uses Foo in 'lcl' alias 'FooLCL', Foo in 'RTL' alias 'FooRTL'

I think this is a reasonable idea, with the following caveats:

1) I think both aliases and namespaces should be identifiers, not strings (i.e. quotes are unnecessary distraction).
2) I think that namespace-like syntax is preferable, i.e. "LCL.Foo", not "Foo in LCL"., additionally, I do think it would do no harm to let programmer use "namespaced" unit without alias.
3) Finally, after a slight variation of syntax to avoid extra 'alias' keyword, we arrive at the following proposed syntax:

uses
  FooLCL=LCL.Foo, RTL.Foo;
begin
   FooLCL.proc();
   RTL.Foo.proc();
end.

which is quite similar to already existing 'alias' feature for types:

type
  TFooLCL=LCLUnit.TFoo;
begin
   TFooLCL.Create();
   RTLUnit.TFoo.Create();
end.

Also a good idea.
Two points:
1) It is very important to allow relative search paths, with well-defined semantics.
Otherwise, projects would quickly become non-portable between machines.

2) Another alternative to consider is path-based namespaces, i.e. "uses Path.To.Lib1.Utils" would
use unit "{project root}/path/to/lib1/utils.pas"
The advantage is no need for extra compiler configuration. I think that ability to use plain
"fpc myproject.pas" to build the whole project is an important advantage which would be lost with your alias proposal.

ok, by me

especially for the namespace (see the wiki page too), it solves the difference between

uses Foo in 'LCL'; // a folder called lcl, in the project
uses Foo in LCL; // the namespace

alias without quotes is sensible too.

2) I think that namespace-like syntax is preferable, i.e. "LCL.Foo", not "Foo in LCL"., additionally, I do think it would do no harm to let programmer use "namespaced" unit without alias.

yes and no:
a) "in" is already established
b) ok, but this must only be allowed in the uses clause. In the uses clause the dot as no ambiguity . In the source it can have (see many earlier mails)
In the source, the unit should only be known by either it's name, or if aliased by it's alias only.

Both alternatives could be allowed, they do not conflict. Unless in $Mode Delphi, the dot will at some time be used in delphi compatibility....

possible => but not my favourite

rather shorten "qalias" to "as"
uses LCL.Foo as LCLFoo

begin FooLCL.proc();

yes

RTL.Foo.proc();

no,no,no
The beauty of the alias is, that the pascal source remains pascal, and not a new form of java or C

also RTL.Foo.proc is ambigious.

there could be a
   unit RTL;
   type Foo=class
     class procedure proc;
   end;

yes, but if you do the above uniot namespace with dot in source, you could also read this as

    unit TFoo, procedure Create(); // in namespace RTLUnit

---
uses RTLUnit.TFoo; RTLUnit.TFoo.Create();

See below: the alias is applied to the existing config , if you move your project to another box, that should be no problem.

If your project uses RxLib, and you want to compile it on another box => then RxLib must be installed ther too (no matter in which location / path). All that is needed is that RxLib uses the same alias, if that is part of the lpk file, and set to RxLib by default (by however offers the download), then it is the same everywhere.

Only:
If you change it on one box (because you got 2 packages with this alias), then you must change it on other boxes too. You could think of all kind of fallback scenarios to ease that, but in hte ned, not worth the bother => how often will it happen?

How much extra compiler config is it i the end?

----
If you add a package, you must add the search path anyway. Adding the searchpath+alias is the same amount of work.

In Lazarus it is odne by the IDE => you add a package dependency => Lazarus adds the path to fpc
In future, the package *.lpk file will contain the name of the desired alias too.

Each supplier of a package, can put the desired default alias in there => if it conflicts, the user changes it....

------
If you do not use an IDE, you must anyway add the -Fu to either fpc.cfg, or command-line => just add it with the alias

-----
So really no work at all.

I think that ability to use plain "fpc myproject.pas" to build the whole project is an important advantage which would be lost with your alias proposal.

Not really

"fpc myproject.pas"

for a project that uses RxLib, only works if RxLib is in the search path => so that needs to be set up anyway, then in future, that should always contain the alias.

----
Now you could mix this with Graeme's idea where the imported unit (RxLib) contains a definition of it's default namespace (if no alias is given in the config)

   unit Rxlib; NamespaceDefault 'Rxlib';

But currently because of the lack of a real packagem, that needs to be in each and every unit of the package...... Not sure about that

anyway=> even if you do, I think the ability to override it in the config (with the extended -Fu) is always good / it is the best way to deal with 2 packages wanting the same Namespace (e.g 2 zip implementations)

Martin

Great feedback, thanks.

I added several point to
http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path

Reffering to
http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path

From previous mails, a further issue has shown up.

If 2 packages come with the same default namespace (e.g "zip") and should both be used within the same project, then the user must rename one of the 2 namespaces.

That however would mean that within this project, the user uses a different namespace to refer to one of the 2 units. If the user attempts to compile the project on a different PC (or publishes it), then the same namespace changes would have to be expected.

It may therefore be desirable to find a way to remap this namespace from within the project (rather than changing the config of the package.

The problem is to find a way for the project to identify each of the 2 conflicting packages in a safe and unique way, without referring to the location/install-path of the package (the install path is local to a PC, and different on others)

Ideas?
-------------

Due to the missing concept of one "package unit", that stores settings for all units in that directory, there is also a question where to store such settings.
Currently one way would be to replicate them to each and every unit in the directory => a real bad idea, because nothing gurantees that the setting will be equal for the whole package....

If there was one "package unit", that could be used to store setting for all units, a unit could have a UUID in addition to a namespace => Then the project could map a new alias to such a UUID.

Martin

Martin wrote

Reffering to http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path

....

Having written this, here is an alternative idea.

Scrapping the -Fu extension (though that could stay, as an additional way).

In absence of a "package" declaration file, each "package" (as in "collection of units in a folder" ), could have a local fpc.cfg file
- This file would not be allowed all kind of settings (since not all settings would make sense)
- this file could:
-- Specify a namespace for the package
-- Specify a UUID for the package

the project could also have such an fpc.cfg config (maybe things could be defined in the main program file? but they may need to be known, if compiling any of the units...)
The program's fpc.cfg file could:
-- override namespaces, by referring to the UUID
So namespace conflicts can be solved per project

----
the

   uses Foo in NamesSpaceBar as BarFoo;

would stay as proposed

Martin.

I agree that resolving ambiguity is a good thing, but still think these two usages are confusingly similar.
In other words, I see this as a (not very strong) argument in favor of dotted notation -- there is no chance of confusion between "uses Foo in 'LCL'" and "uses LCL.Foo", and maybe even "uses LCL.Foo in 'my/math/to/lcl'"

 In the uses clause the dot as no ambiguity . In the source it can have (see many earlier mails)

I see this argument as very weak.
Ambiguity is unavoidable both with and without namespace, nothing can prevent it.
The important things are that:
1) It is detected by compiler
2) It is easily resolved by programmer with minimal hassle I think allowing qualified unit names in the source helps (2), and (with proper implementation) does not change (1).

 In the source, the unit should only be known by either it's name, or if aliased by it's alias only.

This a can agree -- once you introduced the alias, you should convert all the usage to it. I just want to allow using qualified names as well.

Both alternatives could be allowed, they do not conflict. Unless in $Mode Delphi, the dot will at some time be used in delphi compatibility....

BTW, I have read bug 14439 and I am surprised that it is rejected -- I agree that Delphi method is totally misguided, but compatibility is compatibility...

I still prefer my bikeshed color ;-)
Currently, "as" keyword means "convert to a different type", while "=" already has "alias" meaning when applied to types. I think overloading "as" to mean "alias" is not optimal from language design POV.
Still, this is trivial matter, so it may go either way.

Do you think allowing more than one level of nesting is a privilege of Java? ;-)

So what? It can already be written (with types instead of namespaces), and is already ambiguous.
(BTW, currently fpc resolves ambiguity by preferring unit over type. I think it should at least issue a warning).

This is one use case, yes.
But another (and, for me at least, more important) use case is: I have (in a corporate environment) a VCS with many interdependent projects. All used libraries are under version control too, since they often contain changes not (yet) submitted upstream.
When I do a clone, I have all required libraries in subdirectories of the cloned project, so I really *can* do just "fpc myproject.pas".

So at least the relative paths in namespace aliases are an absolute requirement for me, and ability to use "ad-hoc" namespaces without command-line setup would be an advantage too, although not that critical.

I writen the idea: "uses zip IN '/units/my/zip.pas' AS myzip;" above, but I agree the Martin's idea is the better, as I said here: http://lists.freepascal.org/lists/fpc-devel/2010-July/021106.html

IMHO, use just one colon to path and nothing in "uses clause" like: uses
Utils in 'SynEdit' alias SynUtils

MD

Op 2010-07-27 13:27, Martin het geskryf:

I added several point to http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path

[... maybe this is stretching your idea of "packages" a bit, but I thought I would ask either way...]

I like your "packages" idea, it sounds similar to Lazarus Packages (*.lpk), but without the Lazarus IDE requirement. I currently use Lazarus Packages support for managing fpGUI based applications, and would like to see if your idea could fit in with fpGUI too (without needing Lazarus IDE support). The problem I see, is that your "alias/package" only seems to take one directory location for source code (*.pas). For fpGUI, I have a directory hierarchy for the fpGUI sources.

Below is the actual fpGUI directory hierarchy. 'lib' contains the compiled units (*.ppu) for each target platform. Inside 'src' is the various units split between two main directories: 'corelib' for the backend API code, and 'gui' for the higher level visual UI components. 'gui' and 'corelib' contain common code. 'gdi' and 'x11' contain backend specific code.

With Lazarus I had to create two fpgui_toolkit.lpk packages, but in different directories - depending on which platform you are working on. Good news is that your application simply requires 'fpgui_toolkit.lpk', irrespective of it's location, so switching between platforms doesn't break the application compilation.

~/programming/fpgui/

|-lib
|---i386-linux
|---i386-win32
|---x86_64-linux
|---arm-linux
|-src
|---corelib
|-----gdi *--> fpgui_toolkit.lpk
|-----x11 *--> fpgui_toolkit.lpk
|---gui
|-----db

Here follows the extrafpc.cfg file content I pass to fpc when I compile fpGUI from the command line (eg: fpc -dX11 @extrafpc.cfg). You will note that there are multiple -Fu paths and multiple -Fi paths.

-------------------[ src/extrafpc.cfg ]------------------------- # * * * I M P O R T A N T * * *
# You need to specify which backend you are compiling for #
# Your options are:
# -dX11 for X11 support (eg: Linux, FreeBSD, Arm, MacOSX) # -dGDI for Windows GDI support (including WinCE) #

# Slashes are also allowed under Windows
# search path for include files
-Fi.
-Ficorelib
#IFDEF X11
-Ficorelib/x11/
#ENDIF
#IFDEF GDI
-Ficorelib/gdi/
#ENDIF

# search path for units and other system dependent things -Fu.
-Fucorelib/
#IFDEF X11
-Fucorelib/x11/
#ENDIF
#IFDEF GDI
-Fucorelib/gdi/
#ENDIF
-Fugui/
-Fugui/db/

# Unit output path
-FU../lib/$fpctarget/
---------------------------------------------

I can't see your idea working for compiling a fpGUI based application directly from source. But I can see your idea work for projects using the pre-compiled fpGUI units ('lib' directory with *.ppu files), because the latter is only one path. Whereas the sources are multiple source paths and multiple include paths. Am I correct?

I can only use: -Fl=FPGUI:~/programming/fpgui/lib/i386-linux

but can't use -Fu or -Fi: -Fu=FPGUI:~/programming/fpgui/src because the latter doesn't include all the unit and include paths required for fpGUI.

The above is obviously possible with Lazarus Packages, because I can specify multiple search paths in the *.lpk compiler configuration dialog.

Regards,
- Graeme -

I think you have over-engineered it by far ;-)
I see two use cases:
1) Project uses libraries which are not part of the project's source tree. In that case, it already have to contain config files or scripts that somehow determine paths to the libraries and pass it to compiler via -Fu switch
=> So you proposal is already adequate for this use case, when the namespace alias changes, those config files or scripts must change as well.

2) Project uses libraries which *are* part of the source tree => This is the case I wrote about in the nearby thread. Maybe resolved using relative paths in aliases, but also would be helped by path-to-namespace extension.

In any case, no need for UUIDs and other complications.

I understand your argument for LCL.Foo => and IMHO it's amatter of personal taste.

- LCL.Foo is more distinct from Foo in LCL
- but Foo in LCL looks more familiar (well matter of taste)
- Foo in LCL => allows to later use Foo.LCL in mode delphi to implement the delphi thing for compatibility

For the 3rd example:
The namespace LCL is a specification of a location (only by means of an alias). Therefore "uses LCL.Foo in 'my/math/to/lcl'" makes not much sense: "Foo in LCL in 'my/math/to/lcl'" => You can only give one location for Foo.

uses Foo as RxFoo;
...
begin
   RxFoo.bar

is only ambiguous, if in addition to the unit (via alias) there is a type RxFoo. (and then it's the fault of the person who choose the alias....)

- It can not be ambigious with a namespace, if no namespace is allowed/expected in the source
- It can not be ambigious with another unit, since it's unit in the list of both uses-clauses, must have a unique name .

     uses LCL.Foo, RTL.Foo;

is not allowed and gives an error. => both units must be given an unique alias (in theory one would be sufficient, but forcing both may be a good idea)

The important things are that: 1) It is detected by compiler 2) It is easily resolved by programmer with minimal hassle

change the alias => easy

I think allowing qualified unit names in the source helps (2),

Can't see how? The alias is same as good. (If you consider the above rules about it's uniqueness)

and (with proper implementation) does not change (1).

yes, but neither does the alias.

As explained above => I am strictly against it => and this statement was meant to underline the "no qualified" statement.

I listed all possibilities.

But yes the final details of the syntax are not the most important for now....

Not Java only....

But the question is, do we really want to look at a wide selection of other languages (including java and C++) and copy all possible features? There is a difference between extending pascal, and creating a completely new language... We have a tendency to go to the new language....

The fact that some ambiguity exists does not mean that we should seek to extend this.

And also it is not a matter if the compiler can deal with this, never mind if that is:
- resolving by some rule (with/without hint/warning)
- aborting with error

For a compiler it is easy to follow a rule that deals with it.

but for the developper each possibility of creating ambigiuty, decreases readability of the code. And a developper can not resolve the ambiguity as good, quick, or correct as the compiler can.

Not meaning to repeat the developper-shot-himself-in-foot thread. True we can not stop the developper from doingso, if he wants to. But should we supply him with extra ammunition, in case the first bullet misses the target (foot)?

Ah ok, well relative pathes can be done, but question is => do they need the namespace (leaving out the qualified unitname in source)

if you just look at the uses clause => you do not need a namespace then
=> you need "in" to work in units (and not only in program)
   unit foo;
   uses bar in './ralative/path' alias SomeBar;

or

    uses SomeBar = (bar in './ralative/path');

hm, here the = solution looks ugly / and in is correctly used.

----
if -Fu allows relative pathes, then a namespace can be defined there based on the path in -Fu

----
if local fpc.cfg files are used to setup the namespaces => they may as well contain relative pathes

Please see also the latest alternative with local fpc.cfg conf files to set up the namespaces....

....

It shouldn't depend on lpk files.

the lpk files are only for lazarus, the compiler doesn't see them. Any info in them is translated by lazarus for fpc.

For your case, it would simply be necessary to specify the same namespace for multiply -Fu => and as a result expect all of them to be in this namespace

-FuFPGUI:.
-FuFPGUI:corelib/
#IFDEF X11
-FuFPGUI:corelib/x11/
#ENDIF
#IFDEF GDI
-FuFPGUI:corelib/gdi/
#ENDIF
-FuFPGUI:gui/
-FuFPGUI:gui/db/

The only problem with this is, that it wouldn't detect any other package using this namespace => no reflict would be reported, but instead the namespaces be merged -FuFPGUI:/path/to/mfr/package

alternatively (either in-Fu or in local fpc.cfg) =< the namespace can be specified in a separate instruction, specifing that it applies recursive to subdirectories.

having all your directories in -Fu you would do
-FNFPGUI:/path/to/fpguibase/*

the asterisk specifies => recursive

==> need to be added to wiki

Martin

Not sure about the "by far", but the rest is possible true.

However, it also has the purpose of getting the discussion going, and seeing what everyone thinks.

Best is to have a complet list of possibilities, with explanations what each feature can provide (and therefore what will not be without the feature).

From that list a choice can be made.
Once that choice is made, and some one volunteers to implement, the implementer can again discard part of the choice, and make it's own decisions .....

to me one of the really important questions is: Should qualified unit references in the source (outside the "uses") be allowed? My answer is "no" => but that's only 2 cent (my 2 cent)

Sure, this would be the best solution from my POV, (only I would write it as
uses SomeBar = Bar in 'relative/path';
i.e. no unnecessary parenthesis and no starting './', since allowing absolute path inside unit code is clearly insane anyway, so they may be all assumed relative).
However, it was stated rather forcefully at the beginning of the thread that FPC developers do not like this solution (I am not sure why, and maybe I misunderstood).
Hence the need for your '-Fu' hack.

if -Fu allows relative pathes, then a namespace can be defined there based on the path in -Fu

Of course, I was just saying that -Fu _must_ allow relative path for aliasing to be useful for me.

Martin wrote

On 27/07/2010 13:53, Alexander Klenin wrote: Not sure about the "by far"

Sorry about that.

to me one of the really important questions is: Should qualified unit references in the source (outside the "uses") be allowed? My answer is "no" => but that's only 2 cent (my 2 cent)

I do not think it is so very important, but still:
1) I believe that arbitrary restrictions are confusing for a programmer and contrary to the orthogonality principle.
2) Consider what will actually happen: _everybody_ who needs this feature will have to write

uses LCLForms = LCL.Forms, MyForms = My.Forms;
...
LCLForms.TPosition ... MyForms.TPositions...

i.e. in 90% of cases the alias will in fact be a concatenation of namespace and unit name. I see that as forcing programmer into unnecessary code duplication, which is bad IMO.

Martin wrote

Great feedback, thanks. I added several point to http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path

Regarding the following point:

It may be proposed, that if 2 units Utils exists, both must be aliased. Even though, if only one was aliased, they would have different names already.

Forcing to alias both units might not be a good idea. Consider the following:

You have a unit that uses Graphics and Windows (which both contain a type TBitmap).

uses
   Windows, Graphics;
(...)
var
   b: TBitmap;
   bm: Graphics.TBitmap; // I don't remember FPC's current order of
resolution, but in this example Windows takes precedence over Graphics

You use the prefixed Graphics.TBitmap in quite a few locations in that unit.

Now you add a new package that has also some nice graphic routines (but no TBitmap for the sake of example ^^) that also reside in a unit graphics.

uses

   Windows, Graphics, Graphics in GraphicsPkg as PkgGraphics; // I just

picked one of the syntaxes... no need to discuss this here ^^

Now if you force that both units are aliased you'd need to change all references of Graphics.TBitmap to e.g. LCLGraphics.TBitmap. While this can be done in an IDE or with Find & Replace I'd prefer that this is not needed, cause it's simply an unneccessary change.

Regards,
Sven

[cut example]

True, please add to wiki, so it doesn't get forgotten

Martin wrote

True, please add to wiki, so it doesn't get forgotten

Done.

What about the uses clause I wrote by mistake (I corrected that in the wiki entry):

uses
   Windows, Graphics, Graphics in GraphicsPkg as PkgGraphics;

How should the compiler resolve (the LCL's) Graphics? Or MUST "search path identifiers" (e.g. "in LCL") be used if there are two units with the same name in a uses clause (or both uses clauses)?

Regards,
Sven

That's down to the person who implements it...

If the Graphics has no "in" or namespace, then it is resolved as it would be right now.
- if right now the LCL is searched before the other package =>it's finding it in the LCL
- if right now GraphicPkg is searched before the LCL => then the above is an error => as twice the same package is used.

"right now" => current implementation