On Tue, Jul 27, 2010 at 21:35, Martin <f...@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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
