[fpc-pascal] Re: Ideas for namespace implementation
Martin
fpc at mfriebe.de
Mon Jul 26 16:06:23 CEST 2010
On 26/07/2010 14:44, Graeme Geldenhuys wrote:
> Please note: I did not say my ideas are perfect, just that they are
> suggestions that was put out there. Discussions regarding namespaces and
> ideas/suggestions need to filter out the finer details of what could or
> couldn't work. This is the whole point of this discussion at this stage.
>
Which is why I add examples, and question, instead of saying "I dislike
it, simply because I wish to annoy you" ;>
SCNR
>> lets say we have:
>> rtl: classes, sysutils, but *not* foo
>> rxlib: sysutils, foo (all in namespace rx)
>> mylib: foo (namespace my)
>> It the my project itself: sysutils, my (no namespace?)
>>
>> uses classes; // the one from rtl
>> uses sysutils; // the one from my project?
>>
...
> In your example above, sysutils inside the project conflicts with the
> sysutils of the rtl, so the project will have to define a namespace for its
> sysutils
>
ok
>> uses rc.foo, my.foo, my; // there is a unit my
>> ...
>> begin
>> foo.a; // error, which foo?
>> my.foo.a; // is that unit my, record foo.a OR unit my.foo ?
>>
> Good point, I haven't thought that far.
It's from the mantis issue, that you quoted...
> I only worked though of the uses
> clause. Maybe when referencing a namespace we need a different syntax?
> Something that distinguishes between a<unit name>.<var or record>
> reference and a<namespace>.<unit name> reference.
>
> I'm not sure what will fit nicely in the Object Pascal language. Generics
> already uses the< and> characters. The _ is not allowed as the starting
> character of a unit name, so maybe that could be used? Or maybe the #
> character?
>
> eg:
> uses
> rc.foo, my.foo, my;
> ...
> begin
> foo.a; // is the<unitname>.<var or record> syntax
> _my.foo.a; // is<namespace>.<unit name>.<var or record> syntax.
>
Devil's advocate: Why not using the "_" as separator:
my_foo.a // a in my_foo
my.foo.a; // record foo int my
> ...not sure if _ should be used in the uses clause as well for consistency.
> Currently a '.' (dotted) unit name is not allowed in the uses clauses, so
> FPC could know that a 'rc.foo' means<namespace>.<unit>. But consistent
> syntax is probably better, so the uses clause will change to.
>
> uses
> _rc.foo, _my.foo, my;
>
> Second suggestion is changing the _ character to a # character, but then
> again, that conflicts with a hex char notation, so is probably not a good idea.
>
I do not think, that prefixing namespace identifers (# or _) is a good
idea at all. If anything like this, then use a diff separator
my#foo.a // namespace
my.foo.a // record
# is used for chars (hex is #$) => #foo can ot be a char....
So technically possible, but IMHO messy, very messy
>> But worst of all
>> uses sysutils; // the one from my project?
>>
> No, because the RTL is not compiled with a namespace, so falls under the
> "global" namespace with takes preference over project units or all other
> namespaces. This then stays consistent with how developers understood the
> code as it currently works. Compiler included units take preference.
>
You missed the important bit of this section.
let's correct the uses:
uses myspace.sysutils;
// and only this sysutils, not using the global rtl.sysutils at all
....
begin
SysUtils.Exception;
Now if any one else is to read/review/... the code => they will not be
aware of sysutils not being rtl.
They will assume that "SysUtils.Exception" is "RTL.SysUtils.Exception",
but it really is "myspace.SysUtils.Exception"
For me,. that is code obfuscation. In order to keep it human
understandable, the unt name "sysutils" (unqualified) must only be
allowed to refer to exactly one unit => the one from the rtl, no other
one ever.
But if we allow the unqualified to only refer to the original rtl one =>
then all other SysUtils must be fully qualified at any occurence they
have (even if they are the only SysUtils used in that unit).
And if the always need full qualification, then they do not differ from
a prefix (the dot becomes part of the unti name).
Martin
More information about the fpc-pascal
mailing list