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

[Alexander Klenin]

On Tue, Jul 27, 2010 at 21:35, Martin <fpc at mfriebe.de> wrote:
> especially for the namespace (see the wiki page too), it solves the
> difference between
>
> uses Foo in 'LCL'; // a folder called lcl, in the project
> uses Foo in LCL; // the namespace

I agree that resolving ambiguity is a good thing, but still
think these two usages are confusingly similar.
In other words, I see this as a (not very strong) argument in favor of
dotted notation -- there is no chance of confusion between
"uses Foo in 'LCL'" and "uses LCL.Foo", and maybe even
"uses LCL.Foo in 'my/math/to/lcl'"

>  In the uses clause the dot as no ambiguity . In the source it can have (see
> many earlier mails)
I see this argument as very weak.
Ambiguity is unavoidable both with and without namespace, nothing can
prevent it.
The important things are that:
1) It is detected by compiler
2) It is easily resolved by programmer with minimal hassle
I think allowing qualified unit names in the source helps (2),
and (with proper implementation) does not change (1).

> In the source, the unit should only be known by either it's name, or if
> aliased by it's alias only.
This a can agree -- once you introduced the alias, you should
convert all the usage to it. I just want to allow using qualified names as well.

> Both alternatives could be allowed, they do not conflict.
> Unless in $Mode Delphi, the dot will at some time be used in delphi
> compatibility....

BTW, I have read bug 14439 and I am surprised that it is rejected --
I agree that Delphi method is totally misguided, but compatibility is
compatibility...

>> uses
>>   FooLCL=LCL.Foo, RTL.Foo;
>
> possible => but not my favourite
>
> rather shorten "qalias" to "as"
> uses LCL.Foo as LCLFoo

I still prefer my bikeshed color ;-)
Currently, "as" keyword means "convert to a different type",
while "=" already has "alias" meaning when applied to types.
I think overloading "as" to mean "alias" is not optimal from
language design POV.
Still, this is trivial matter, so it may go either way.


>> begin
>>    FooLCL.proc();
> yes
>>    RTL.Foo.proc();
> no,no,no
> The beauty of the alias is, that the pascal source remains pascal, and not a
> new form of java or C

Do you think allowing more than one level of nesting is
a privilege of Java? ;-)

> also RTL.Foo.proc is ambigious.
>
> there could be a
>  unit RTL;
>  type Foo=class
>    class procedure proc;
>  end;

So what? It can already be written (with types instead of namespaces),
and is already ambiguous.
(BTW, currently fpc resolves ambiguity by preferring unit over type.
I think it should at least issue a warning).

-- 
Alexander S. Klenin