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

[Sven Barth]

On 26.07.2010 18:17, Martin wrote:
> 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

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