Hi,

As I stated in another thread, namespaces are not perfect, but they do work, and they do greatly reduce the chances for unitname or classname conflicts. Other languages and frameworks (Java, .NET, C++ etc) already showed this.

How visible is the unit name conflict problem? Just think, how many projects are there that use the unit names (or would like to use these common names):
constants.pas
utils.pas
etc...

Extremely common names, and are really good names for what they contain, so why can't we use them in our projects? Namespaces will resolve this problem. What we need to discuss, is how to implement namespace support in FPC.

Some ideas I can think of... please list your own if you have some:

1) Follow the "dotted" notation for unit names as implemented in Delphi. Cons:
- They force rather long unit names, which is frowned upon in the Pascal community (for whatever reason).

Ambiguities couldn't appear, but they are rather easy to overcome with a simple language rule. Object Pascal already have many language rules, this will just be a new one.
See the following Mantis report for details:
http://bugs.freepascal.org/view.php?id=14439

2) Another idea is in a way similar to how compiler defines work. This idea tries
to resolve the problem in (1) with long unit names and with least amount of resistance to existing code. A namespace can be applied to a single unit, or to a group of units (think of it as a "package"). To get this to
work, we will have to introduce a new keyword and a new compiler parameter. Here follows examples of both.

    // per unit
   unit utils namespace companyxyz;
   uses
     ...
   end.
    ... or applied at compile time to all units being compiled.
    // our sample unit - as normal, nothing new
    unit utils;
    uses
      ...
    end.
    $ fpc -namespace=companyxyz utils.pas constants.pas ...

... if a conflict occurs, then you reference the unit with the full namespace.
eg:

      uses
         companyxyz.utils;  // because unit names must be valid
identifier and thus,
                                      // can't contain dots, when the
compiler sees this, it knows
                                      // companyxyz. is a namespace reference.

Pros:
- No long unit names are required.
- We can use all the easy unit names for projects. eg: utils.pas, constans.pas etc.
- Can be applied to existing code without any code changes, simply by adding a new namespace compiler parameter when compiling that existing code. Thus, FPC's RTL and FCL, or fpGUI or Lazarus etc could apply it too, to
their makefiles.
- referencing via a namespace is only needed when a conflict occurs, other than that, units are used as normal.
- If no namespace is specified, then it automatically falls under the "global"
namespace - maybe using the namespace value "global" and will be similar to all units containing the following:
eg:

            unit myunit namespace global;
            ...
            end.

... or being compiled with 'fpc -namespace=global <units>'

3) Automatically add the directory where the unit is located, as the namespace. Similar to what Java does.

I'm sure given more time, I could come up with some more ideas, but I rather like (2) because it could be applied to all existing code, without any code changes required.

Michael Van Canneyt wrote

What unit name conflicts ? In 15 years that I work with Delphi and FPC, and I have use many many packages, I encountered exactly 1 conflict:

Then you are extremely lucky. I have experience stacks of unit name conflicts in my years of programming. Have you never had the urge to use the unit name: constants.pas? utils.pas?

the strutils of rxlib, which conflicted with strutils introduced in a later version of Delphi. The RX copy was renamed to rxstrutils, and that was it.

A perfect example of the problem!
* Compilers get preference over the easy and well descibed unit names, while other projects must now rename there units.
* Other projects now have to live with crappy named units with ugly prefixes.
* can't use underscores because for some reason it is frowned appon, so now you
get odd looking units where the prefix ends with the same letter as the original unit names.

Utilities functions that work on Strings - wouldn't it make sense to have them in a unit: strutils.pas?
Currently we can't, even though the unit name perfectly describes the function of that unit - so we have to shun from the ideal name. If we don't, we are guaranteed to get conflicts in our projects. So now only the "compiler" projects like Delphi or FPC my use such names - that is crap.

I am sorry, but I think that the seriousness of the problem is very much overestimated. Wanting to type rx.strutils versus rxstrutils. Really ?

And my suggestion (2) will reduce such syntax *only* when a conflict has occured, without long unit names.

And let us not forget: most component vendors must support older versions of Delphi, so they are barred from using the dotted unit name syntax anyway.

Which option (2) I suggested will also handle via a namespace compiler parameter or the 'namespace <value>' in the unit, but declared inside a IFDEF checking for compiler version: eg

unit utils {$IFDEF Ver2_4_x} namespace myproject {$ENDIF};
uses
  ...
end.

No. Because I don't see the difference between having to type

uses
   wisa.utils;

versus

uses wisautils;

The latter is even shorter. So I really don't see the gain.

The discussion is not about namespaces. Object Pascal HAS namespaces, namely units. The discussion is about 'enhancing' the namespace to allow one or more dots in the name.

That said, I don't really care whether the . ends up in the compiler or not, but I do think it is much ado about nothing. Yes, it may be nice to have, but no, it is not urgent and not the end of the world if we don't do it.

Unicode strings is orders of magnitude more important.

Michael.

Michael Van Canneyt wrote

The discussion is not about namespaces. Object Pascal HAS namespaces, namely units. The discussion is about 'enhancing' the namespace to allow one or more dots in the name.

With the importance that the '.' is only needed when resolving a conflict - all other instances, you will just use the unit name as normal. Also, the '.' usage is only limited to the uses clause. At least we will be able to easily use more logical unit names without the fear of getting unit name conflicts.

Unicode strings is orders of magnitude more important.

I wasn't arguing what is/isn't more important that other tasks. I'm gathering information and feedback on a feature request to enhance namespace support to reduce unit name conflicts. Just because Unicode strings haven't been implemented yet, doesn't mean we maybe implement something else.

Regarding the cpstrnew branch:
I'll try and resolve my Unicode String branch (cpstrnew) compilation issues this coming week (or at least report the issue with more details). Since the resync with Trunc, I can't compile that branch, and thus can't submit my local changes I have so far.

Hi!

I personally don't have a real opinion pro or against extended namespace, so I'll try to answer as neutral as possible.

Regarding your ideas 2 and 3: as they are not Delphi compatible they might be considered a "bad thing" (TM) by the FPC developers.

The problems of all three (or maybe all namespace ideas) is that they aren't compatible to older versions of Delphi (and FPC). Even if your second idea including compiler version checks is used, you'd be back at the start, because now you'd have a conflicting unit name.

Example:
I'll take the strutils example from rxlib:

unit strutils {$ifdef ver2_6_0}namespace rx{$endif};
(...)

So now we use a 2.4.0 compiler or a Delphi compiler and have a problem: How can I use the strutils from FPC/Delphi from a unit that uses strutils from rxlib?

The only solution to this might be

{$ifdef ver2_6_0}
unit strutils namespace rx;
{$else}
unit rxstrutils;
{$endif}

But now it gets ugly regarding uses-Clauses in rxlib itself and units that use rxlib. :(

Regarding your idea 3:

As FPC can use different directories for the search paths how would you solve similar hierarchies?
Or a different problem: the source units of FCL packages reside in packages/$PackageName/src/ while the compiled units are in units/$Target/$PackageName/. What namespace should apply here? Where is the base of the namespace? Is it the FPC base dir? What about units that aren't part of FPC, like fpGUI?

Your idea 3 might become the most complicated one, because of the search path features that FPC has in comparison to Java.

If I'd have to choose one of your three ideas I'd choose the second one although it has some backwards-compatibility problems. But there still might be better ideas out there. :)

Regards,
Sven

Op 2010-07-26 10:14, Sven Barth het geskryf:

Regarding your ideas 2 and 3: as they are not Delphi compatible they might be considered a "bad thing" (TM) by the FPC developers.

Currently FPC developers do not want to implement the "dotted" namespace idea from Delphi - though they already stated there stance on Delphi compatibly regarding this. In short - Delphi in-compatibility is not a problem here, just like Generics or Compiler Modes or ..... FPC doesn't do everything like Delphi, sometimes it does things _better_ than Delphi. FPC Namespaces would hopefully fall under the latter.

The problems of all three (or maybe all namespace ideas) is that they aren't compatible to older versions of Delphi (and FPC).

I don't see this as a problem at all.

* Currently they have unit name conflicts. No solution other than renaming the offending unit. Even if they introduced the "dotted" namespace idea from Delphi, it is not supported by FPC, so you still sit with a problem. You are forced to rename the unit. See the RxLib example.

* Simply upgrade your FPC to a newer version. FPC is FREE. You don't have the burden of Delphi upgrade costs. FPC development is open, so you can prepare your code as you see things change in FPC, so that when a new version comes out, you already are compatible with it (again unlike Delphi - remember Unicode support in Delphi. Users had no warning of its syntax and required changes until AFTER Delphi was released.).

Regarding your idea 3: As FPC can use different directories for the search paths how would you solve similar hierarchies?

Idea 3 is crap - I see lots of issues too, but thought I would mention it simply because that is what JAVA uses.

Regards,
- Graeme -

Hi!

I hope this, too. And personally I am not interested in Delphi compatibility because I only use Delphi (6) at work and there we use a stable set of compatible components. And the few times I used units from FPC to achieve something (TProcess, SQLite interface unit) I was able to adjust them to the Delphi compiler.

Yes, FPC is free and examples where an older version of FPC is needed can only be constructed artificially, but the Delphi case still holds. E.g. tiOPF supports Delphi besides FPC.
I don't know the unit structure of tiOPF but suppose you have a unit "utils" that once conflicted with a Delphi unit and was renamed to eg. "tioutils".
Now FPC introduces the new namespace system and you'd like to jump the train and make tiopf "namespace aware". Now you rename the "tioutils" unit again to "utils" and set the prefix to "tiopf". Now you've upset the Delphi users in two different ways:
1) They need to change their uses clauses
2) Now the unit conflicts again with a Delphi provided "utils" unit (does Delphi have a "utils" unit? it's an example after all...)

Or would you keep the "tioutils" unit name and just introduce the namespace? But what did you gain then?

So... what is your suggestion for such packages providers to solve the problem?

Please note again: I'm not against this "unit Foo namespace Bar" idea and the more I think about it the more I like it, but I also tend to see problems that arise because of such a feature and to discuss solutions for such problems.

I didn't want to say it that directly ^^

Regards,
Sven

Well, I fail to see what is more logical in my.constants than in myconstants. The unit is still called my.constants, not constants. So you'll end up typing my.constants everywhere anyway. The gain of this over myconstants is highly debatable.

Since (as jonas points out) it introduces an ambiguity and violates the rule that a unit name must be a pascal identifier, the pros must be weighed against the contras. The contras are known.

The only pro argument that carries any weight is Delphi compatibility. All the rest is a matter of personal opinion.

Given that, I suspect that if someone supplied a patch that allows dotted unit names *in delphi mode* (with matching resolving algorithm), it would not be rejected. But I also wouldn't hold my breath waiting for one of the core developers to implement it. Clearly, none of them sees the need for it, at least that should have become obvious from the thread.

Michael.

Op 2010-07-26 11:34, Michael Van Canneyt het geskryf:

You are confusing the point. (excuse the pun) :)

My preferred namespaces implementation is *not* the dotted unit names like Delphi currently have. My preferred method (see my other message thread) would be a 'namespace' keyword and a new -namepace= compiler parameter. Unit names will stay the same as the currently are - a legal identifier without the use of extra dots in the unit name.

In my opinion, this is a much better idea than what Delphi implemented.

Regards,
- Graeme -

Op 2010-07-26 11:18, Sven Barth het geskryf:

In the case of tiOPF, it already prefixes all units with 'ti' and all classes with 'Tti'. The same as what fpGUI does. This reduces the chances of conflicts, so such code can stay the same, especially if that code is used both under Delphi and FPC.

My suggestion of namespaces is purely for FPC and FPC compatible code - *not* Delphi. Why, because Delphi namespace support already exists, and will not be implemented as such in FPC. So lets leave cross-compiler projects out of the discussion, because they are a "special" case with different rules.

Now FPC introduces the new namespace system and you'd like to jump the train and make tiopf "namespace aware". Now you rename the "tioutils" unit again to "utils" and set the prefix to "tiopf".

For FPC only projects, that would be fine with me, and those projects would make a final release before the unit name change (for users that want compatibility without namespaces support). Any future development can then take advantage of namespaces and more logical unit names without ugly prefixes.

Just to show how ugly unit names look with prefixes. eg:
tiUtils.pas vs tiutils.pas vs utils.pas

Under OSes that have filesystems that are case sensitive (like under Linux), the norm is to use lowercase filenames. But with prefixes, it makes such unit names hard to read, and mixing cases make unit names inconsistent and prone to errors. Whereas, if you where free to use a simple unit name without prefixes, you get easy to read and consistent lowercase names.

Regards,
- Graeme -

Graeme Geldenhuys wrote

In short - Delphi in-compatibility is not a problem here, just like Generics or Compiler Modes or ..... FPC doesn't do everything like Delphi, sometimes it does things _better_ than Delphi. FPC Namespaces would hopefully fall under the latter.

I'd say that the way FPC handles things different than Delphi in some cases is worse. Take generics, which you mentioned.

type
  generic TSomething<T> = class

is worse than

type
  TSomething<T> = class

The only reason I can see having put the word "generic" in front of the identifier, something which Pascal has never done (put keywords in front of identifiers when declaring types), was to make it easier for the compiler author. That is to say, negate the need to look ahead.

Just to show how ugly unit names look with prefixes. eg: tiUtils.pas vs tiutils.pas vs utils.pas

Is this really a problem that warrants time to develop and test a solution? Two letters?
Well, it is your time after all.
So I vote for the solution that is the least intrusive, meaning that I don't have to change my code much R.

Let me see, if I got the idea (Graeme's idea) correct.

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?
uses rtl.sysutols;   // rtl
uses foo;  // error ambigious?
uses rx.foo;  // rxlib

Am I correct so far, that his is the plan?

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 ?

----------
But worst of all
uses sysutils; // the one from my project?

Now if any one else is to read/review/... the code => they will not be aware of sysutils not being rtl.
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.

----------
even:
uses rs.sysutils
...
begin
sysutils.a; // againg, it is "sysutils" onlt, any reader should be correct to think it is from the rtl and the rtl only

if sysutils ever refers to anything but the rtl, it will (highly) obfuscate the code.

----------
or "foo" in the above example.

let's say it wasn't part of rx. And my project uses the packages rx and my. then
uses foo; // from package my, since it only exists there.

Nor rx is updated, and suddenly contains a unit called "foo" => and all code breaks
Well it would break without namespaces too, but still namespaces hasn't helped avoiding the breakage.

Yes, maybe in this case namespaces can help fixing the breakage, but at the cost of code obfuscation...

Hi,

I created a wiki page for this to consolidate ideas.

http://wiki.freepascal.org/Namespaces

Regards,
- Graeme -

Op 2010-07-26 14:34, Martin het geskryf:

Let me see, if I got the idea (Graeme's idea) correct.

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.

No. I envision that not defining a namespace means if falls under the "global" namespace, and the global namespace takes priority. So with saying that, FPC's RTL would probably be compiled as-is without defining any namespace, giving it search priority.

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 unit. eg: 'unit sysutils namespace myproject;' or compile the project with a namespace compiler parameter.

uses rtl.sysutols; // rtl

As I mentioned above. Reducing the amount of required changes (which would make FPC developers happy), means that the RTL is not compiled with any namespace, so to reference the RTL's Sysutils unit, you would simply use: uses

    sysutils;

uses foo; // error ambigious?

Yes, just like you would get with the current FPC compiler (which doesn't have namespace support). You need to specify which namespace the 'foo' unit belongs too. Neither the RTL nor the project contains a 'foo' unit, so the compiler will give a conflicting unitname error (or something like that).

Good point, I haven't thought that far. 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.

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

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.

Regards,
- Graeme -

Which is why I add examples, and question, instead of saying "I dislike it, simply because I wish to annoy you" ;>

SCNR

...

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

It's from the mantis issue, that you quoted...

Devil's advocate: Why not using the "_" as separator: my_foo.a // a in my_foo

   my.foo.a; // record foo int my

I do not think, that prefixing namespace identifers (# or _) is a good 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

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

Hi!

Are you sure that "_" is not allowed at the beginning of a unit name?

=== source start ===
unit _test;
interface
implementation
end.
=== source end ===

Compiles without problems.

What about using ":" as a starting character for namespaces? It should be less problematic than "#" (even when used in type/variable/parameter declarations).
Other possibilities are "!", "?", "~", "%", "|", "\" and """ as they aren't used yet as far as I'm aware of... (please correct me here if necessary ^^)

Regards,
Sven

Hi!

What about that the compiler enforces that you use the fully qualified name if you used it in the uses?

e.g.

uses
   myspace.sysutils; // this sysutils contains an identifier "Exception"
begin
   Exception; // no error
   SysUtils.Exception; // identifier not found
   MySpace.SysUtils.Exception; // no error
end.

So the declaration of "myspace.sysutils" declares a new pseude-identifier. By using a different separator or prefix this could be made even less problematic for "new users/readers" (I'll chose "~" now for the sake of example):

uses
   myspace~sysutils;
begin
   Exception; // no error
   SysUtils.Exception; // identifier not found
   MySpace~SysUtils.Exception; // no error
end.

With RTL's sysutils:

uses
   sysutils, myspace~sysutils;
begin
   Exception; // normal resolution of duplicated types, so sysutils wins
(or does the last one win? - I can't remember now...) => no error
   SysUtils.Exception // the RTL's Exception
   MySpace~SysUtils.Exception; // Exception from MySpace~SysUtils
end.

Hmm... "~" looks ugly :P

Regards,
Sven

IMHO, is better to use the ':' like myspace:sysutils

uses
  myspace:sysutils;
begin
  Exception; // no error
  SysUtils.Exception; // identifier not found
  MySpace:SysUtils.Exception; // no error
end.

MD

IMHO, is better to use the ':' like myspace:sysutils

Even better C++ style:

uses
  myspace::sysutils;
begin
  Exception; // no error
  SysUtils.Exception; // identifier not found
  MySpace::SysUtils.Exception; // no error
end.

R.

Sven Barth wrote

What about that the compiler enforces that you use the fully qualified name if you used it in the uses?

Not only if you used it in the uses clause, but if you COMPILED with namespace sintaxe (eg. by Graeme unit strutils namespace my), IMHO... But we would have a problem stated by Michael:

So... maybe create a new directive like as {$NAMESPACE ON}

eg.

{$NAMESPACE ON}
unit strutils namespace my;

With {$NAMESPACE ON} all units will have namespaces, unless FPC's units.

MD

Op 2010-07-26 16:23, Marcos Douglas het geskryf:

> > Hmm... "~" looks ugly :P IMHO, is better to use the ':' like myspace:sysutils

That does indeed look better.

Regards,
- Graeme -

Yes, but only if have a problem with the sintaxe namespace:unit, I think.

MD

Op 2010-07-26 16:10, Sven Barth het geskryf:

Are you sure that "_" is not allowed at the beginning of a unit name? Compiles without problems.

I wasn't. Thanks for confirming. So indeed the ugly _<namespace> syntax can't be used.

I quite like Marcos Douglas's idea of using a colon between the namespace and unit name. Similar syntax already exists in C++, so it's not 100% alien to programmers. :-)

Regards,
- Graeme -

Yhat is the point I was trying to make.

If I understand correctly, Graeme wants namespace, so the prefix/namespace could be left away => resulting in shorter and depending on personal taste better looking names.
I believe Graeme explicitly stated, that he wants to use "utils" and not "graemeutils" in his code.

But, exactly that is the problem. If you allow the same (same, if not fully qualified) identifier, for different things, then it makes the source unreadable (obfuscated).

And yes, it was said, there are already rules for resolving names. And some more or less make no different: They may make no different to a piece of software, like the compiler => the compiler can resolve the rules in a blink. But humans can not, and humans are error prone. Deliberately encouraging ambiguous names, is (as far as human readability goes) a really bad thing.

And so that leaves to enforce full qulification always. => which is true, makes the need for namespaces redundant. It makes no diff if it always is:
myutils or my.utils
The dot increasing the readability => but so would an underscore my_utils. The _ may be frowned up on, but that does not mean there is a technical issue with it, it's simple a style. And if the dot would be allowed, then it was no better than the underscore, it could quite quickly be frowned up on too?

Not sure why a directive?

To allow none fully qualified names? Then we a back to square one.

Hi everyone,

Could you please move this thread to the fpc-devel list?

Thanks,

Jonas
FPC mailing lists admin

To allow ONLY qualified names (using namespaces) not to have syntax problems cited earlier (eg. foo.bar.a is using namespace or not?). But was just one idea...

MD

In our previous episode, Graeme Geldenhuys said:

IMHO that is just the stance of Jonas. But dotted unit names or not, or a solution to your problem are two totally different things, since you mix in all kinds of namespace ideas.

I think that most, if not all delphi incompabilities will be fixed in the end. If not by core, than by 3rd party patches, and in the end the first good patch that fixes delphi compat on a language level (*) still has to be refused.

(*) codegenerator or debug info like changes are a different matter, like
the stuff with the moment when interfaces are released.

Like Michael,

I see units as namespaces already existing: we use the unit names to prefix ambiguous function or variable names for example.

In addition, units are similar (but simpler) to Ada packages, which are much more robust than namespaces. If we want to go the full way, let's implement Ada packages instead of namespaces, by extending the unit concept. (see here for an example : http://www.adaic.org/whyada/intro4.html)

Let's not add yet another concept to manage the naming. Units and types are enough. One issue is for example, what would happen to the interface and implementation of units, if an additional namespace is introduced? How would the conflicts be managed? Would there be private units or public units?

I vote for robust Ada packages, if we need them. Such packages can form a hierarchy, can be visible or not from other packages. In addition, we would have the ability to separately compile the interface and the implementation sections of the unit, which is not possible currently with FPC.

Thierry

rtl package generate rtl.dll or rtl.so (not yet in fpc)

i can use
uses

  rtl.sysutils, mypackage.classes;

or

uses
  sysutils in rtl, classes in mypackage;

we can declare the package/namespcase as like in delphi

package mypackage;
uses
   myunit;
end.

Thanks for the your patient.

Thierry Coq wrote

I see units as namespaces already existing: we use the unit names to prefix ambiguous function or variable names for example.

Unit Names give very limited namespace support - which only applies to types or procedures/functions or global variables (anything in the interface section of a unit). They to not resolve unit name conflicts. eg: RTL contains a constants.pas unit, but I want to create a constants.pas unit in my project too. With the state of unit name rules at the moment, this is not allowed. The units included in the compiler always takes preference, and everybody else has to keep renaming units, and do search & replace until no conflicts occur.

And that sure is enough - unless you want to extend to Ada's package concept (which in fact is more than just "namespace") and even there you are not immune to name conflicts. I suppose you know that as you were the one who suggested it. ;)

But then, IME (most) name conflicts are a sure sign of inproper names. Take the example of "constants.pas": What sort of constants shall I expect there? Screen sizes, color codes, electron mass or the gravitational constant?

Namespaces are a clutch added to C++ because being stuck with C-compilers they simply had no proper solution. Remember, in C _every_ visible identifier is in the same scope. There are no "units".

Vinzent.

In our previous episode, Anthony Walter said:

I'd say that the way FPC handles things different than Delphi in some cases is worse. Take generics, which you mentioned.

Worse or not is a personal matter of taste.

Keep in mind that the Delphi syntax (since essentially C++) was considered too.

And afaik that was indeed the main reason to do it this way. Short lookaheads and as little ambiguity and context dependance of syntax was considered more pascal.

You right about "constants.pas".
Then I would like to give other example: StrUtils.pas What we expect in unit StrUtils or "Strings Utilities". Is very clear. But we can't use this name. That is the problem (no for FPC's units because we all know their names).

Namespaces are a clutch added to C++ because being stuck with C-compilers they simply had no proper solution. Remember, in C _every_ visible identifier is in the same scope. There are no "units".

MD

Marcos Douglas :

So we can't use it because somebody already written it for us? So why do you want to write it again? Just kidding. (Well, if it were Ada you /could/ create a child package of StrUtils and add your very own subroutines to the original package, but FPC isn't Ada.)

Back to your two StrUtils... Now you do what? Invent a "MyStr" namespace to put your own "StrUtils" into it? And if somebody already did that with his very own version of StrUtils? You rename your namespace again?

See my point? Actually, name clashes will occur every now and when. There is *no* way around it unless you start the whole Java-crap with unique domain name prefixes and even that is not 100% bullet-proof.

IMO, if there is no further concept of child units (maybe similar to Ada) there is no point in adding namespaces to FPC, it's not worth the trouble. After all, it's still a name and if somebody else already uses it, you still need another to disambiguate.

Funny story that is somewhat related: I know that in some town where I lived there are two women with the exact same name, born at exactly the same date. Shit happens. Well, one of those at least was put into another namespace after she married. ;)

'nuff said.

Vinzent.

:P
You know... StrUtils was just an example ;-)

(Well, if it were Ada you /could/ create a child package of StrUtils and add your very own subroutines to the original package, but FPC isn't Ada.)

That is very interesting :)

Back to your two StrUtils... Now you do what? Invent a "MyStr" namespace to put your own "StrUtils" into it? And if somebody already did that with his very own version of StrUtils? You rename your namespace again?

That is the problem we are discussing! =)

See my point? Actually, name clashes will occur every now and when. There is *no* way around it unless you start the whole Java-crap with unique domain name prefixes and even that is not 100% bullet-proof.

But you saw some ideas in this (and many others) thread? eg:
uses Utils in RxLib alias RxUtils

...sounds a way to this problem.

IMO, if there is no further concept of child units (maybe similar to Ada) there is no point in adding namespaces to FPC, it's not worth the trouble. After all, it's still a name and if somebody else already uses it, you still need another to disambiguate.

But if you can CHOOSE the name of alias for the units of others programmers, in MY project, then I can see a possible solution, don't you?

Funny story that is somewhat related: I know that in some town where I lived there are two women with the exact same name, born at exactly the same date. Shit happens. Well, one of those at least was put into another namespace after she married. ;)

Before married, the namespace were the name of father and mother, not your name! =)
Very funny...

Thanks,
MD

Ok, in this case Graeme (sorry Graeme) is wrong to blame FPC for taking the Name => We all should thank FPC for taking it => it prevents everyone else from taking it, and reduce the amount of very likely conflicts.... ;>

SCNR

See my point? Actually, name clashes will occur every now and when. There is *no* way around it unless you start the whole Java-crap with unique domain name prefixes and even that is not 100% bullet-proof.

see the UUID idea (admittedly a bit over engineered...)

IMO, if there is no further concept of child units (maybe similar to Ada) there is no point in adding namespaces to FPC, it's not worth the trouble. After all, it's still a name and if somebody else already uses it, you still need another to disambiguate.

Yes, Namespaces (those on top of units) will inherit the same conflict problem that units have. That is as long as the inherit the same source...

That means, if the namespace for a unit is given to that unit by the writer of that unit, then 2 writers of 2 units will eventually give the same namespace to equally named units....

*if*, but what is if not. What is if the namespace is not set by the writer of the unit, but instead of that by the user of the unit.

The user will always know if 2 units do conflict => so he can then set a namespaces => and because the user (as in the writer of the final program) knows already all the names, and decides all the namespaces himself => there will be no conflict.

that can be done by giving the namespace to an include path -Fu / -FU (if necessary recursive)
=> only draw back, you have to do it equally for every PC /installation that you use....
(unless the UUID thing....)

Then again, it is only worth the bother, if someone actually deems it worth his/her time to implement it....

Martin

As I said:
[[

But if you can CHOOSE the name of alias for the units of others programmers, in MY project, then I can see a possible solution, don't you?

]]

MD

I was thinking... if we could use a nickname, for an unit, just to reference it on the code?
The unit (same) name problem still happen, I know... then I have to rename my units with long names (this is worse) but I could codify with bit names in my code.

eg:
the unit mycompany_strutils.pas will be referenced on the code:

uses
   mycompany_strutils as stru;
begin
  stru.Foo('str foo');
end;

Got it?
Is this more easy to implement?

Regards,
Marcos Douglas

This looks like the import as statement in Python : http://www.python.org/dev/peps/pep-0221/

Best Regards.

Exactly :)

Marcos Douglas

Do not need to change the engine of search units (but we'll have to use long names for units to not happen conflict names) and we can work with bit names. If will exists a conflict name with any function/classes/variable names, just use unit name as prefix.

You guys, what do you think about it?

Best regards,
Marcos Douglas