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

[Martin]

On 27/07/2010 13:28, Alexander Klenin wrote:
> 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'"
>
>    
I understand your argument for LCL.Foo => and IMHO it's amatter of 
personal taste.

- LCL.Foo is more distinct from Foo in LCL
- but Foo in LCL looks more familiar (well matter of taste)
- Foo in LCL => allows to later use Foo.LCL in mode delphi to implement 
the delphi thing for compatibility

For the 3rd example:
The namespace LCL is a specification of a location (only by means of an 
alias). Therefore  "uses LCL.Foo in 'my/math/to/lcl'"  makes not much 
sense: "Foo in LCL in 'my/math/to/lcl'" => You can only give one 
location for Foo.


>>   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.
>    
uses Foo as RxFoo;
...
begin
   RxFoo.bar

is only ambiguous, if in addition to the unit (via alias) there is a 
type RxFoo. (and then it's the fault of the person who choose the alias....)

- It can not be ambigious with a namespace, if no namespace is 
allowed/expected in the source
- It can not be ambigious with another unit, since it's unit in the list 
of both uses-clauses, must have a unique name .
     uses LCL.Foo, RTL.Foo;
is not allowed and gives an error. => both units must be given an unique 
alias (in theory one would be sufficient, but forcing both may be a good 
idea)


> The important things are that:
> 1) It is detected by compiler
> 2) It is easily resolved by programmer with minimal hassle
>    
change the alias => easy
> I think allowing qualified unit names in the source helps (2),
>    
Can't see how? The alias is same as good. (If you consider the above 
rules about it's uniqueness)

> and (with proper implementation) does not change (1).
>    
yes, but neither does the alias.


>>   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.
>    

As explained above => I am strictly against it => and this statement was 
meant to underline the "no qualified" statement.


>>> 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.
>    
I listed all possibilities.

But yes the final details of the syntax are not the most important for 
now....


>>> 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? ;-)
>    
Not Java only....

But the question is, do we really want to look at a wide selection of 
other languages (including java and C++) and copy all possible features?
There is a difference between extending pascal, and creating a 
completely new language... We have a tendency to go to the new language....

>> 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).
>    
The fact that some ambiguity exists does not mean that we should seek to 
extend this.

And also it is not a matter if the compiler can deal with this, never 
mind if that is:
- resolving by some rule (with/without hint/warning)
- aborting with error

For a compiler it is easy to follow a rule that deals with it.

but for the developper each possibility of creating ambigiuty, decreases 
readability of the code. And a developper can not resolve the ambiguity 
as good, quick, or correct as the compiler can.

Not meaning to repeat the developper-shot-himself-in-foot thread. True 
we can not stop the developper from doingso, if he wants to. But should 
we supply him with extra ammunition, in case the first bullet misses the 
target (foot)?