alias = namespace [Re: alternative aliases [Re: [fpc-devel] Re: [fpc-pascal] Re: Ideas for namespace implementation]]

[Martin]

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