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

Martin fpc at
Mon Jul 26 17:49:08 CEST 2010

On 26/07/2010 16:45, Sven Barth wrote:
> On 26.07.2010 17:27, Martin wrote:
>> 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';
> 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?

-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


More information about the fpc-devel mailing list