On 27/07/2010 13:28, Alexander Klenin wrote:
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'"
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)?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
