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
?
Read
http://lists.freepascal.org/lists/fpc-devel/2010-July/021088.html
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
Martin
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
