<p>Am 13.09.2017 15:33 schrieb "Mattias Gaertner via Lazarus" <<a href="mailto:lazarus@lists.lazarus-ide.org">lazarus@lists.lazarus-ide.org</a>>:<br>
><br>
> On Wed, 13 Sep 2017 14:38:55 +0200<br>
> Sven Barth via Lazarus <<a href="mailto:lazarus@lists.lazarus-ide.org">lazarus@lists.lazarus-ide.org</a>> wrote:<br>
><br>
> >[...]<br>
> > I'm not talking about ambiguity, I'm talking about aesthetics: FooBar.Blubb<br>
> > is easier to discern visually than FooBarBlubb.<br>
><br>
> Well, aesthetics often goes together with "used to".<br>
> I'm used to a point separates a sub identifier.<br>
> The Delphi namespace concept breaks this rule. E.g. in a namespace<br>
> "org.fpc" the dot is part of the identifier. Try "org.|" with the<br>
> Delphi code insight. It does not show all possibilities. Lazarus code<br>
> completion works better here.</p>
<p>We all know that Delphi isn't the best example of an IDE out there :P</p>
<p>> > Also were is there an ambiguity anyway (given all units are used with their<br>
> > full name)? The compiler reads (in my above example) the token sequence ID<br>
> > Point ID and thus can find the unit without any backtracking just as for<br>
> > ordinary methods. Even once the default namespace option is added that<br>
> > won't change as the compiler will simply test all provided namespaces as<br>
> > prefixes and then the name as is. It's just a longer list of names than<br>
> > usually to test for.<br>
><br>
> Let's say you have 'a.b.c.d'. Before namespaces the compiler could<br>
> simply resolve a, then b, then c and finally d.<br>
> With namespaces the compiler has to read the full 'a.b.c.d',<br>
> then search for a.b.c, then a.b, then a and then resolve the rest as<br>
> before.</p>
<p>Ah, using the identifier inside code. Okay I grant you that one regarding ambiguity...</p>
<p>Regards,<br>
Sven</p>