[fpc-devel] Namespaces like URLs

Martin fpc at mfriebe.de
Tue Jul 27 07:49:26 CEST 2010

On 27/07/2010 03:30, Adem wrote:
>  On 2010-07-27 5:06 AM, Martin wrote:
>>> 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
>> ?
> 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?

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?

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

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

and the other msgs in that thread

>>>> 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
> Of course you can. As long as they are identical where it matters.
"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)

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


More information about the fpc-devel mailing list