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

[Marcos Douglas]

On Mon, Jul 26, 2010 at 1:27 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
> 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

This is cool, but duplicate names may still exist.


MD