Hello guys,

I'm new to free-pascal.

Will fpc 2.7.x have some namespace implementation/support?

Thanks

It already has.

Michael.

How it works?

I have tried to use the Delphi style dotted unit notation but doesn't work. I'm using Lazarus 1.0.12 - fpc 2.6.2.

Thanks

Aha: 2.6.2 - You write it :-)

Support is in 2.7.1

Michael.

But I have asked "will fpc 2.7.x have... " ^^...

It uses the Delphi style notation?

Fabrício Srdic wrote

But I have asked "will fpc 2.7.x have... "  ^^...

Yes, and I said: it is already implemented.
Obviously, that means it is in 2.7.1.

It uses the Delphi style notation?

It does.

Michael.

Thanks!

When the fpc 2.7.1 will be released?

Fabrício Srdic wrote

Thanks! When the fpc 2.7.1 will be released?

Not in the near future. At least one more year, I suspect.

Michael.

Just for completeness sake (since you mentioned to be new with FPC) - you may be able to use it earlier in the form of snapshots (see link "Development" on our WWW page). Once the current trunk version (2.7.x) will be released, it will have version 2.8.0 (releases have even numbers, odd numbers are interim versions / snapshots).

Tomas

2013/10/23 Tomas Hajny

Any sample showing how to use it?

2013/10/23 Tomas Hajny

Any sample showing how to use this feature?

23.10.2013 21:45, silvioprog пишет:

Any sample showing how to use this feature?

Either look at fpc tests:

http://svn.freepascal.org/svn/fpc/trunk/tests/test/tdotunits1.pp http://svn.freepascal.org/svn/fpc/trunk/tests/test/tdotunits2.pp http://svn.freepascal.org/svn/fpc/trunk/tests/test/tdotunits3.pp http://svn.freepascal.org/svn/fpc/trunk/tests/test/tdotunits4.pp

Or use google/yahoo/bing/yandex.

Best regards,
Paul Ishenin

Although you already got an answer please note that you can read about comming features on the following page:
http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk

Best regards,
Paul Ishenin

2013/10/23 Paul Ishenin

Thank you very much!

Michael, how Delphi-compatible is it? In Delphi I can use (maybe not the best example) the reference Forms.Application and in the project compiler settings I can say if it is the VCL or the FMX namespace, so it knows at compile time which Application global variable to use. I personally haven't used namespaces, but during recent tiOPF discussions, such an example was presented to me - for use in a future tiOPF v4 branch (where namespaces will be used to differentiate between FMX, VCL etc. LCL and fpGUI probably too).

How do you tell FPC which namespace a project is using?

Regards,
- Graeme -

Michael Van Canneyt wrote

It already has.

When the fpc 2.7.1 will be released?

Since you ask this, obviously you don't understand fpc release engineering. This will enlighten you: http://www.freepascal.org/faq.var#versions

And as an answer to your question: it will NEVER be released, not as 2.7.1, but probably as 2.8.0 or 3.0.0.

Thanks a lot!

2013/10/23 leledumbo

Specifying default namespaces (which was AFAIK introduced with XE2) is not yet supported in FPC though it's definitely planned to add support for this. Otherwise namespace support should be compatible to Delphi 2009.

Regards,
Sven

Thanks for confirming my statements :)

Michael.

With the new namespace support feature, will the fpc standard and base units be structured into packages?

e.g types -> system.types; winsock -> windows.winsock; winmouse -> windows.winmouse

2013/10/24 Michael Van Canneyt

Would it bring any benefits? E.g. having unit winsock under "windows" isn't necessarily so logical for targets like os2 or netware/netwlibc (regardless of the fact that library winsock obviously has its origins in MS Windows).

Tomas

In our previous episode, Fabr?cio Srdic said:

e.g types -> system.types; winsock -> windows.winsock; winmouse -> windows.winmouse

Delphi uses winapi, not windows.

And I see no need. There is so much code in use that assumes the standard names, and I don't see a need to force existing codebase users to rename everything just to free up a few unit names for packages that are essentially free to chose their own.

There is a need. Without it, you will severely cripple the use of default namespaces.

If someone
* defines a namespace 'mycompany',
* uses that namespace as the default namespace
* has a 'classes' unit (or anything else that name-clashes with our units) in that namespace he/she will never be able to use our classes unit again.

This is not so far-fetched as it may seem, becaus this kind of thing is exactly why namespaces were invented, so you CAN choose your names to match FPC unit names. So people that use namespaces are likely to do so.

So you have something like

{$NAMESPACE MyCompany}
uses Classes; // Adds MyCompany.Classes

So, how to add our own classes unit to the uses clause ?

You can probably work your way around it, but if the FPC distributed units have namespaces, there is no problem.

I'm not necessarily advocating this, but it seems to me that if you enable use of namespaces, putting all FPC units in appropriate namespaces is the logical and consequent thing to do.

Michael.

In our previous episode, Michael Van Canneyt said:

Yes. And he deserves it IMHO.

I don't consider (XE2+) scenarios like this a reason to rush the renaming of units and make dual maintenance between older Delphi versions and FPC harder, and/or need more configuration.

IOW there are scenarios where freeing up the common identifiers are important, but as said they are far fetched (since that person would have to have started with this after XE2, and being blissfully ignorant of the world before that)

This is where support for default namespaces from Delphi XE2 comes in. After all XE2 uses that as well to keep old Delphi VCL applications working despite having changed all units to namespaced ones. Whether we define our default namespaces in the fpc.cfg or we put up a big note that says that one now needs to add option -FN... (assuming for a second that N is not yet used ^^) is up for debate though... (Lazarus could add this option automatically if it detects a compiler where the RTL uses dotted names, but the project's units contain e.g. "SysUtils") Of course providing the possibility to change this per unit-global directive (as indicated my Michael's mail) might come in handy as well...

Regards,
Sven

Strange reaction.

As I said: the above scenario is the very reason why namespaces were invented to begin with.

We make a feature available, and then you are going to say to users of this feature "if you use it as intended, it is your own fault, you deserve what you get"

What kind of attitude is that ?

We can discuss the desirability of the namespaces feature. I am of the opinion that we didn't need OK, Delphi compatibility and so on. We know the reasons.

But if we do decide to introduce them, then we must be consequent all the way through and support their use as intended. That includes IMHO releasing a RTL/FCL whatnot with all the proper namespaces.

Michael.

.
.

But if we do decide to introduce them, then we must be consequent all the way through and support their use as intended. That includes IMHO releasing a RTL/FCL whatnot with all the proper namespaces.

What would be "the proper namespaces" for FPC - the namespaces chosen by Embarcadero (which may change from one Delphi version to another - not sure whether it happens in reality, of course, but the point is that it would happen completely outside our control) without any consideration of our own structure (e.g. rtl versus packages)? Or a different structure for FPC (e.g. fpc.rtl...., etc.)? Are there any implications for our own units (the argument about possible conflicts applies to them too)?

Tomas

These are things I didn't consider yet.
First the principle, then the practical details.

In each case: if we chose in the past to have compatible names for compatible units, (basically: system, classes, sysutils, strutils, rtlconst and syncobjs, and maybe some DB units) I see no reason to abandon that practice.

And Embarcadero would shoot itself in the foot by changing the namespaces too frequently. So I'm banking on the fact that they will not do this too often.

Michael.

In our previous episode, Michael Van Canneyt said:

Not that I can see. It seems that Embarcadero used it mostly for own purposes, not the users, and their support scenarios.

We make a feature available, and then you are going to say to users of this feature "if you use it as intended, it is your own fault, you deserve what you get"

I see it as a cost/benefit tradeoff. It is not the namespace added feature that I worry about, but the fact that you force all existing users to find out what is going on and set default namespaces in their projects.

True. But it is now the time to force this XE2+ breaking change, while you are so opposed of doing the same for the D2009 string change?

And at least that is a major deal, the namespace stuff is rarely benefiting anybody, but forcing updates on all.

But if we do decide to introduce them, then we must be consequent all the way through and support their use as intended. That includes IMHO releasing a RTL/FCL whatnot with all the proper namespaces.

So let's not introduce them then. Or at least wait with breaking changes till the platform is there and older versions are mostly dead.

The discussion is about a namespace feature.
Namespaces exist in other languages as well, and have certain characteristics.

How Embarcadero uses them is secondary.

No one forces anything. You can perfectly set the default namespace to 'fpc' (or whatever) in the default config file, and all should compile as it was. People that do not like this, can change it.

Really, you are looking for problems where there are none.

I don't oppose anything.

And let us not forget that in the FPC team, I am the one advocating 2 sets of units:

1 ansistring set, without namespaces. (roughly D7 and below) 1 unicodestring set, with namespaces. (roughly D2009 and above)

In my opinion, this constitutes exactly:
1. Being very consequent.
2. Caring about backwards compatibility.
3. Offering the user a choice.

Michael.

In our previous episode, Michael Van Canneyt said:

No, it is about your interpretation for what it is meant. Fact is that from D7 till XE2 it was not widely in use, and after mostly only for FM vs VCL.

Namespaces exist in other languages as well, and have certain characteristics.

Maybe. But they are mostly described as the cure for clashing global identifiers, for which we already have units, and (for Java and C#) a way to organize source.

How Embarcadero uses them is secondary.

No, it is primary, since the Delphi compatible use comes from there.

Yes. One can live with the XE2+ renaming at the cost of renaming units, potentially fixing breakage later, and a lot of adaptation of existing configuration, scripts etc.

But I repeat: what is the hurry?

People that do not like this, can change it. Really, you are looking for problems where there are none.

Trouble is that I also think the problem that is solved is none.

I really don't see the need to rush the XE2+ part that is breaking.

In my opinion, this constitutes exactly: 1. Being very consequent.

Leaving out D2009-DXE?

2. Caring about backwards compatibility.

Only the one you want. I'm more interested in D2009 compatibility than I am in D7 compatibility.

Default namespaces again.

> 2. Caring about backwards compatibility. Only the one you want. I'm more interested in D2009 compatibility than I

am

in D7 compatibility.

Backwards compatibility in context of FPC does normally not mean Delphi compatibility to any version, but compatibility to older FPC versions.

Regards,
Sven

I am not hurrying anything.

Where did you see me saying anything about timeframes ? The necessary default namespace support is not even there.

I'm discussing principles, not timeframes.

And the issue of compatibility: It is a bogus discussion, you know this as well as I do. If Delphi itself is not compatible between versions, then we cannot do so either, and must choose a version to which we are compatible (2 versions if you accept/count the 1-byte RTL).

Whether that turns out to be D2009 or DXE1/2/3/4/5: I honestly couldn't care less.

Michael.

I know I'm a newbie in fpc, but I don't see backward compatibility a reason enough to leave to implement some improvements, like organize the base units of the fpc into proper namespaces.

As Michael and Sven said, if Delphi itself is not fully compatible among versions, why should fpc be?

According to the on-line documentation, fpc has five units that are specific to the Unix context. So, why not keep them in a Unix specific namespace? If we have several elements that are platform-independent, why not keep them in a specific namespace, like e.g "System"?

As the number of units of the fpc increases, keeping related elements logically organized can even facilitate maintenance tasks.

To a novice like me, would be easier to locate and to identify what elements which are present in a e.g Windows.API.Messages or Windows.API.Mutex unit than in a huge Windows unit.

2013/10/25 Michael Van Canneyt

Not really namespace related, but:
Most of the commercial/free/open source Delphi/FPC libraries are backward compatible to D7-D6 (including all Delphi-win32 versions) That comes with a cost (a bless) of not using new language syntax (as much as possible).
And typically include a long-long ".inc" that instructs the compiler to be as much convservative as it can (fighting Delphi cross-version incompatibilities)

So from language environment perspective, the hard usage of "namespaces" is most likely will be limited to a certain set of projects.

thanks,
Dmitry

I know I'm a newbie in fpc, but I don't see backward compatibility a reason

enough to leave to implement some improvements, like organize the base units of the fpc into proper namespaces.

Backward compatibility is what the market is mostly about, most companies don't want to change their codebase as much as possible while still getting new features like new optimizations.

As Michael and Sven said, if Delphi itself is not fully compatible among versions, why should fpc be?

Because fpc is NOT delphi, fpc SHOULD BE better than Delphi IMO (I think it's already at some points: cross platform compatibility, proof of compiler capabilities through bootstrapping, etc).

Novice would become intermediate and advanced as time and learning go by, but the opposite won't happen.

I'm not against namespacing standard units, but there must be a way to retain backward compatibility. I have huge libraries I wrote myself and I don't want to change them, while I might need them for new projects. At the worst, a tool to convert existing code to new one automatically should be provided, though it's not the best solution IMHO. A compiler option might be better.

"Fabrício Srdic" wrote

I know I'm a newbie in fpc, but I don't see backward compatibility a

reason enough to leave to implement some improvements, like organize the

base units of the fpc into proper namespaces.

We value backwards compatibility very high as there is much code out there.

As Michael and Sven said, if Delphi itself is not fully compatible among

versions, why should fpc be?

Because we are better. ;)

Regards
Sven

Sven and Leledumbo,

I agree with the importance of backward compatibility, but I disagree when it becomes a reason to stop the implementation of improvements in the tool.

I remember the nigthmare of migrating my existing codebase to D2009 because of your new UnicodeString support. But, with this change, we became able to create apps with fully localization support. In my opinion, that is a great improvement!

Of course, we have to try to minimize any side effect or impact that a change can cause, but when is impossible to avoid them, i believe that implementing
the improvement is more important.

Regards

2013/10/26 Sven Barth

In our previous episode, Fabr?cio Srdic said:

I know I'm a newbie in fpc, but I don't see backward compatibility a reason enough to leave to implement some improvements, like organize the base units of the fpc into proper namespaces.

It depends on the improvement. And IMHO this is a meagre one, if done just for the case a rare developer needs it. (any feature will be (ab)used sooner or later by somebody)

It becomes a different matter if it leads to regular issues because some major third party component starts using it, but till then IMHO it is just more trouble than it is worth. And nearly all OSS and commercial packages still support pre XE2 delphi versions now.

That is a bit the timeframe tradeoff I was discussion about with Michael.

In our previous episode, Dmitry Boyarintsev said:

That's basically the essence of my position yes.

Fabrício Srdic wrote

I agree with the importance of backward compatibility, but I disagree when it becomes a reason to stop the implementation of improvements in the tool.

Well, no. You shouldn't say "improvement". Because "improvement" has positive context, already.
Instead, you should use the word "change" which is more neutral.

So let me paraphrase you: "I agree with the importance of backward compatibility, but I disagree when it becomes a reason to stop the implementation of changes in the tool."
Doesn't sounds so bright, right? Because it's unknown if a change is good, if it helps or if it is beneficial.

So whenever a change comes in it is typically being reviewed by following categories:
* why is the change needed? (Delphi compatibility)

* what's the benefit of the change? - the most important question here - is what the change gives to developers, that they couldn't do earlier?
* what's the disadvantage of the change? - there's always at least one disadvantage present - the language itself gets more and more complicated. (the minimalistic approach is typically followed, as it makes the language as a tool more "lightweight" and easier to master and learn)

Any change passes that review (not just namespaces). a change with the benefit:
1) "a pascal developer is not be to XXX at all with out this change" - are typically accepted without much discussion (i.e. support of ObjC/JVM/LLVM targets)
2) "a pascal developer can do XXX, but the change YYY should make it better, but might be FPC specific" - typically inspire some productive discussions. (i.e. generics, I'd add Unicode rtl here as well) and change typically comes into the compiler;
3) "a pascal developer can do XXX, but the change makes it look like YYY, which is delphi compatible" (i.e. class-helpers, sealed classes) - are typically ignite a lot of discussions and flamewars between conservative and modernists developers. However, the change is typically being added to the compiler (under a certain mode or modeswitch).

In the end, it is up to a pascal developer to either keep using XXXs or switch the code YYYs.
And a pascal developer can be sure that there're far more other developers that do understand XXX than the ones who understand and use a YYY. Thus getting help (and maintenance) with XXX-based code, is more likely to happen.

thanks,
Dmitry

2013/10/26 Dmitry Boyarintsev

If the namespace feature isn't a improvement, so why was it added to fpc?

Fabrício Srdic wrote

I know I'm a newbie in fpc,

myself.. even after almost a decade ;)

As Michael and Sven said, if Delphi itself is not fully compatible among versions, why should fpc be?

because FPC (and lazarus) strives to be better? and to not alienate those who use it by forcing them to adjust all their working code when a new version comes out?

i have nothing more to offer on your other statements but i can agree with them to a point... but then there is documentation that shows what is what, right? :)

Fabrício Srdic wrote

If the namespace feature isn't a improvement, so why was it added to fpc?

compatibility with delphi products that use it??

2013/10/26 waldo kitty

I'm a Delphi user for years.

So, let me see:

D2009 "forced" us to adjust our existing code base to its new UnicodeString support, but in return it give us internationalization support and new possibilities.
D2010 have introduced the namespace feature and DXE2 "forced" us to adjust our existing code base to its new unit scope names - namespace of its base units - but in return it give us new possibilities to organize our existing code base through namespaces, a feature that is present in all other entreprise-class dev platforms - e.g Java and .NET - promoting code reuse and providing us a more clear RTL and API.
Other examples include the addition of Generics and the changes to many classes like TList and so on.
Today, after "forced" us to adjusting our code base many times, Delphi provide us generics, closures, namespaces and internationalization support.

Its a great evolution, do not you think?

On the other hand, fpc community seems to be resistent to implement some improvements - sorry, "changes" - that Delphi already has because it "forces" the users to adjust some peaces of their existing code base.

So, what do you mean when say "be better than Delphi"? Be more backward compatible and in other hand have fewer features than Delphi?

I really don't understand this kind of reaction.

Fabrício Srdic wrote

D2009 "forced" us to adjust our existing code base to its new UnicodeString support, but in return it give us internationalization support and new possibilities.

Again, this is not really accurate. Internationalization is provided by underlying text-rendering engine. In Delphi case - Windows OS. So multilingual has been there from the start. All you had to do was using proper API calls together with either VCL components or 3d-party unicode aware components. WideString took care of that nicely. People who wanted multilingual support - had it.

D2010 have introduced the namespace feature and DXE2 "forced" us to adjust

As Marco said earlier (multiple times in other threads) namespaces are used in Java and .NET as either languages don't have "units". Adding "features" just because "enterpise-class dev platforms" have them is more marketing move, than actual technical need.

I must assume you had no problems organizing your code while working D2009 w/o namespaces?
Were you unable reuse the code you wrote without namespaces? Were your units and code that you created unclear to you?

No, these are sales points and language overloading features.

On the other hand, fpc community seems to be resistent to implement some improvements - sorry, "changes" - that Delphi already has because it "forces" the users to adjust some peaces of their existing code base.

Of course.
I had to pay for a new compiler that forces me to spend more time (and money) to update the existing code, that has been debugged and possibly introduce new bugs and loose even more time (and money) by fixing them? I seriously doubt. That's why there're companies who are still using D6+ as well as 3d components are keeping up with D6+ compatibility.. That's also another reason, why they would stick to the good-old Delphi, rather than try to port their code to FPC/Lazarus.

So, what do you mean when say "be better than Delphi"? Be more backward

compatible and in other hand have fewer features than Delphi? I really don't understand this kind of reaction.

Well, this is not a real discussion anymore, but a pure flame. So before Jonas comes in and sends everyone to fpc-other, I'd say the following:

You don't have to understand. Just follow the corporate guide blindly. Every new feature is a bless. Spend you time and money in constant update of what you have. Btw, they probably have a business plan of releasing the new compiler version (yes - with new features) every other year.

thanks,
Dmitry

2013/10/27 Dmitry Boyarintsev

We can't nest units to form a hierarchical content. With namespaces, we can. Furthermore, namespaces can be used to disambiguate identifiers with the same name, eliminating the need to prefix our identifiers. It's a pure techinical argument. This is not about "just because enterprise-class platforms have them".

Yes, i had no problems while working with D2009 and my units weren't unclear. But with the use of the namespace feature, organizing my code got much better and new possibilities were added.

Other examples include the addition of Generics and the changes to many

On Sat, Oct 26, 2013 at 11:37 PM, Fabrício Srdic
wrote:
.

I believe only global scope identifiers needs to be prefixed? Yet again, it's not problem for pascal from the start as specifying a unit name resolves the problem in the first place:

uses unitA, unitB;
t:=unitA.calcFunc(param1) + unitB.calcFunc(param2);

any locally scoped-identifiers (i.e. object/class/record fields, class methods) doesn't need prefixes.

Yes, i had no problems while working with D2009 and my units weren't unclear. But with the use of the namespace feature, organizing my code got much better and new possibilities were added.

So, if you've the code reorganized to D2010, is there a sample, from your personal experience, where re-namespacing actually helped (by saving time and/or somebody's efforts)?

They couldn't use Delphi 6 forever, as the Windows and the hardware changes more and more. What will happen when they have to change?

Very true! They can't, especially if they want a new target platform. This is there FPC comes into play with its carefully guarded backward compatibility. (who knows may be {$mode goodolddelphi} will show up}! So at the time, when they'll have to get away from D-Old, they'll have 2 options - rewrite a lot of code and jump to D-New or rewrite none of the code and jump to FPC.
Either jumps would require the same amount of testing efforts anyway.

thanks,
Dmitry

Furthermore, namespaces can be used to disambiguate identifiers with the

same name, eliminating the need to prefix our identifiers

How does that differ from existing <unit name>.<identifier> solution?

In our previous episode, Fabr?cio Srdic said:

Yes. But that doesn't need renaming all existing units. It is that part that I think that is excessive.

Embarcadero did it probably to keep their hands free for some long term VCL phase-out (IOW that they wouldn't have to rename FM to avoid VCL names).

We don't have any major such problems, and thus renaming everything is a bit draconical to me. At least till we really have a reason to do so.

Furthermore, namespaces can be used to disambiguate identifiers with the same name, eliminating the need to prefix our identifiers.

That is the main reason why it is added to so many languages;

BUT, Unit based Pascal never had that problem, since units already have their own namespace.

Namespaces are only for pseudo hierarchical disambiguation of unit names in Pascal.

2013/10/27 Marco van de Voort

In my opinion, the change of the fpc's base units to use namespaces is a positive change. The side effect is that requires adjustment of the existing codebase. I believe there are some approaches to address this problem, if the fpc dev team decide to namespace base units. Maybe, unit aliasing can be used.

Very true. I agree with everything.
BUT, IMHO, the only problem is if you have two 3rd frameworks that use the same unit name. In that case I can not add 2 units with the same name in my project. So, only in that case, we could use 'namespaces' to 'rename' these units only for use in our projects without change the original source.

Best regards,
Marcos Douglas

In our previous episode, Marcos Douglas said:

In theory yes, in practice no, since that would be incompatible with anything below XE2+ (and most commercial component builders still support D7).

As with any feature, there are people that already design it in after the first beta, but it will be rare, very rare, in the wild.

2013/10/27 Marco van de Voort

Namespace address this problem, but as the Marco said, not to anything below XE2.

Yes and how I still use D7 at work I still have this problem. This problem happen not only for unit names but component names too. I can not register two components with the same name. So, because that, programmers around the world use prefix in class names. If the components were registered using 'unit+class_name' and when we drop a component on the Form the IDE write the unit name as a prefix, this problem not will happen.

My more fresh example is:
I have, for years, many units that have the prefix 'M'. So I have MClasses, MCore, MTasks, MSystem, etc.
Now MSEgui (by Martin Schreiber) introduced a mclasses unit -- your own implementation of classes unit -- and I can not use both units in the same project. :(

As with any feature, there are people that already design it in after the first beta, but it will be rare, very rare, in the wild.

Sorry, I didn't understand what you mean. :(

Regards,
Marcos Douglas

As Dmitry Boyarintsev wrote -- as Marco said before: Adding "features" just because "enterpise-class dev platforms" have them is more marketing move, than actual technical need.

Pascal do not need 'namespaces' like Java or .NET have. Units are namespaces. Point. But I think, IMHO, that missing something to the design be perfect: "rename unit virtually"
We already had many discussions about it on this list, but nothing is good enough and/or nobody have time to implement it; or nobody agrees.

I think it was Graeme Geldenhuys wrote this page:
http://wiki.lazarus.freepascal.org/Namespaces

Regards,
Marcos Douglas

In our previous episode, Marcos Douglas said:

Yes and how I still use D7 at work I still have this problem. This problem happen not only for unit names but component names too. I can not register two components with the same name.

True. But is maybe because RTTI (and .classname) didn't allow to get the unitname for a class. Since D2009 that afaik is possible, and it is unrelated to namespaces.

Keep in mind that Delphi (1)'s original design was still 16-bit, and thus they tried to minimize memory use.

Ah, that's an interesting example.I hardly use the component registry myself.

So was the issue fixed?
I'd suggest to renamed your MClassess to MDgClasses or not to use MSEgui at all. The best approach here is to rename only 1 collision at a time - at least this is what I would do. The fix is pretty easy - renaming the file itself and all uses section of units that are using it. (prevents updating to D2010 for namespaces)

I doubt that Martin would agree to rename his MClasses to MSEClasses, since more people is using the library (that's my guess).

Is there a risk of bloating the program by duplicatrd code? It sounds to me that Martin's and yours MClasses are doing pretty much the same thing. With Namespaces such code duplication will become very welcomed.

thanks,
Dmitry

Ok.
But if this problem happen in two third-party codes? How will you fix this? Change the third-party code yourself?

I doubt that Martin would agree to rename his MClasses to MSEClasses, since more people is using the library (that's my guess).

There is a mseclasses already... so, he can't rename to mseclasses. But it was just an example.

Namespaces, IMHO, should allow the user (programmer) to change the path -- or something smarter -- where they can not change third-party library codes.

Marcos Douglas

My more fresh example is:

I have, for years, many units that have the prefix 'M'. So I have MClasses, MCore, MTasks, MSystem, etc.
Now MSEgui (by Martin Schreiber) introduced a mclasses unit -- your own implementation of classes unit -- and I can not use both units in the same project. :(

Namespace does NOT solve the problem. If MSE units uses M.<unit> for their units and you have yours the same as well, you'll end up renaming either anyway.

leledumbo wrote

Namespace does NOT solve the problem. If MSE units uses M.<unit> for their units and you have yours the same as well, you'll end up renaming either anyway.

I would have thought that is exactly what namespaces will be handy for! Or at least a popular use-case. Macros Douglas could define a "douglas" namespace, and the MSEide+MSEgui project could define a "msegui" namespace. Units, Classes or even lines of code should be able to say which namespace they are referring too.

Regards,
Graeme

Please, see my mail before.

The major problem is using third-party codes. You do not have access to change these codes -- well, you could but you would miss the updates from original one.
I do not like Java, for example, but this language allows the programmer make your own paths and use them in 'uses' (import) clause. The problem of Pascal language isn't Namespace support because we already have it (unit). The problem, IMHO, is do not have the flexibility to change the 'path' and/or the 'name' of 'Namespaces'.

Marcos Douglas

I am strongly against this last solution. ;-)

There is a mseclasses unit in MSEgui already. The "mse" prefix is used for MSEgui units, "m" prefix is used for forked FPC units. Maybe it should be changed to "mfp" or the like. Marcos, what do you think? FPC AFAIK does not support unit alias option so it will break existing code.

Martin

So, what you're looking for is to change a "unit search priority" for a specific units compiled:

// use a unit.
-Fu/path/mse/msegui.pas
// set the units search priority path

In that case, if MClasses is used by "msegui.pas", "Mclasses" from /path/mse will be used, instead of "Mclasses" found elsewhere? If any other unit uses MClasses, it will be using MClasses that's found first.
Hmm, and compiler will have to create two separate "mclasses" object files (and update the reference appropriate) .

And that should solve (unit or namespace) name collisions throughout 3d-party components.

thanks,
Dmitry

The "mfp" prefix sounds good for me. :-)
I guess don't exist a framework around the world that uses this prefix... until now. ;-)

Regards,
Marcos Douglas

Then the John Douglas and Douglas McKey are running into the same issue. Both guys (while living on different parts of the world) created the same "douglas" namespace!

Similar to using the same "M" prefix for classes unit.

What option do these three guys would have now? Elevate another the level of name space?
john.douglas
macros.douglas
mckey.douglas
douglas.mckey?

Is it much different than just extending the prefix "M" to "MFP"?

thanks,
Dmitry

P.S. Offtopic: I personally find it horrible to call a unit "classes" (it's fine for RTL, since it's started this way, but any other library - it is horrible). Nobody calls their units like "functions" or "functionsandprodures" (though I think I saw unit "funcs" one day), It is better to give more accurate name of the unit functionality: StrLists, UnicodeUtils, FileUtls, DateUtils.

Is it much different than just extending the prefix "M" to "MFP"?

+1

Nobody calls their units like "functions" or "functionsandprodures" (though I think I saw unit "funcs" one day)

I admit that I use "settings" or "config" quite often, though they're meant to be application specific instead of general library

mseclasses unit is the unit of tmsecomponent class which extends the FPC TComponent with object linking facilities and the like and is base of all MSEgui components. Before forking of FPC classes unit it also included the code for workarounds.
But agreed, classes unit should be split into smaller functional units. Although then it would not be possible anymore to have so much private elements as now and to make the life of the toolkit producers so much more difficult. ;-)

Martin

OK, ok, my example was bad. I would apply the exact same namespace rules as recommended by Java. In a real situation you should use your domain name for the namespace.

But I get what you say... conflicts could still occur. And so too in Java, but the usage of the "company domain name as namespace" greatly reduces the chances of a conflict.

I must admit, Martin (from MSEgui project) was silly to simply use the "M" prefix. It is too easy to have conflicts. That is why I choose "fpg_" as the unit prefix and "Tfpg" as the class prefix for the fpGUI Toolkit project. The chances of conflicts are much less, but obviously still possible.

Sure, but much more common unit name issues is Constants.pas or Utils.pas.
They are ideal names, but are too common, and often cause conflicts with other projects or component packages.

Regards,
Graeme

Is it much different than just extending the prefix "M" to "MFP"?

Of course it is not, actually it's about the same, as you know. IMHO it's not even a feature just another horrible idea of the Delphi guys used to get their VCL and FM stuff working and of course it was an entry for the 'new features' list of the Delphi release. Pascal already has namespaces and they can clash. The 'new' namespaces can clash, too.
- two units with the same name => clash
- two prefixed units with the same prefix and the same name => clash (less likely than above)
- two units with the same name in two namespaces with the same name => clash (same as above)

It's just another 'stay compatible thing'. And that's the reason why it will be implemented no matter what. So arguing against it is a waste of time. I'd be a lot happier if the 'compatability features' would be only implemented in mode Delphi but most likely it's easier not to and it reduces the risk of fragmentation.

R.

+1

Marcos Douglas

You didn't understand.
The namespace we talk about is like a "dinamic namespace". The programmer can choose which "names" he will use in your projects when these projects are using third-party frameworks.
In Java, eg, you can change the path of frameworks, changing the "namespace", without change the original sources.

The RTL, LCL, whatever... all these libs have horrible names.

Regards,
Marcos Douglas

In our previous episode, Graeme Geldenhuys said:

Only if you use fully qualified unitnames only. As soon as you start messing with scope prefixes you risk conflicts again.

+1

But I get what you say... conflicts could still occur. And so too in Java, but the usage of the "company domain name as namespace" greatly reduces the chances of a conflict.

I agree.

FPC uses "fpg" prefix too. You did not have to go so far... ;-)

[offtopic]
Another type of conflict happens -- but no one talks about it -- using procedure/function with the same parameters in different units. Eg: GetHandler(); If you use two units that have a GetHandler function, in a third unit, you have a trouble.
Do you (all) use prefix in Procedures and/or Functions too? ;-)

Regards,
Marcos Douglas

Do you (all) use prefix in Procedures and/or Functions too? ;-)

Nope, we use classes and methods instead of global procedures and functions. ;)

R.

Another type of conflict happens -- but no one talks about it -- using

procedure/function with the same parameters in different units. Eg: GetHandler(); If you use two units that have a GetHandler function, in a third unit, you have a trouble.
Do you (all) use prefix in Procedures and/or Functions too? ;-)

It's a FEATURE, not a trouble. I often use it to switch between two implementations of certain functionality, treating the unit as singleton object.

Once upon a time, Marcos Douglas said:

Do you (all) use prefix in Procedures and/or Functions too? ;-)

Unitname.GetHandler() ?

Me too but, unfortunately, not everyone thinks so.

Marcos Douglas

I know this is part of language... but problems can happen eg: You can add a new unit, maybe a 3rd-party, called A3rdFunc.pas that have the same function (GetHandler) what you already use in another unit called MyFunc.pas.
Someday you will add the A3rdFunc unit on 'uses' -- AFTER the MyFunc -- and now your program can be broken.

Marcos Douglas

Ewald wrote

Once upon a time, Marcos Douglas said: > Do you (all) use prefix in Procedures and/or Functions too? ;-) Unitname.GetHandler() ?

Yes, works... but the language allow hide the unit name and nobody uses unit name as an identifier in 99% of cases, Am I right? So, problems can be happen.

Marcos Douglas

I thought I did, but named it differently.
Isn't what you're trying to explain is suggestion #3 at this page? http://wiki.freepascal.org/Namespaces

Instead of modifying the code (i.e. by switching to namespaces) You would like to give then compiler a hint what unit should be used when compiling a unit.

In other words, you'd like to unit-specific -Fu, that should override the project -Fu.
Right? or am I still misunderstanding.

thanks,
Dmitry

I actually had to use the explicit unit name in probably 2% of the code. Back from Delphi days: some of the functions between WinAPI (windows.pas) and VCL (sysutils.pas) are actually using the same name. So specifying the exact unit name is required to get the code compiled properly.
There were some collisions on MacOSX (carbon) type names with LCL type names.
So it's not that unrare thing to happen.

And as you've given example above. If I'm writing a unit that uses two separate units with the same identifiers reused, I'd recommend to specify a unit name explicitly. (Just not to rely on a compiler doing it right for you).
uses

  windows, graphics;

var
  wb : Windows.TBitmap;
  gb : Graphics.TBitmap.

or

uses
  windows, graphics;
type  // declare once, use everywhere
  TWindowsBitmap = Windows.TBitmap;
  TGraphicsBitmap = Graphics.TBitmap;
var
  wb : TWindowsBitmap;
  gb : TGraphicsBitmap.

thanks,
Dmitry

On Tue, Oct 29, 2013 at 3:51 PM, Dmitry Boyarintsev <

Yes.

IMO, the problem is:
You can not use two unit with the same name.
So, you can point -- using -Fu -- which unit the compiler will compile but you can't used both at the same project.

Regards,
Marcos Douglas

Yep, this is a good tip if you have a couple of types and works. But, if you have two or more units that have many types and/or functions that have the same name, then this job -- create an alias -- is boring. I had this problem just one time in my life, I confess, but happened.

But, little collisions happen easily -- using procedures/functions is more easy -- because, as you said, we only use the unit name as a prefix (2% code) only if we know, previously, that we should use.

I guess I will not convince you, right? :)
That's Ok.

Regards,
Marcos Douglas

I guess, technically it should be possible to use two different units with the same name.

I recall there was a discussion a while (few years) ago, about (re)using Delphi introduced 'in' syntax (afaik, it is not available in pascal). uses
unitA in 'unitA.pas'
,unitAA in '.\some\other\place\unitA.pas'
Don't remember what was the conclusion of the conversation. Yet again, this "in" solution is only allowed at either "program" or "library" units.

But from the compiler's perspective, if there're two units with the same name, it would need to solve two problems:
1) decide the rules on what units are using what unit of these 2. (That's why it was proposed to introduce an extension to -Fu or some other switch)
2) decide about the "object name" for each unit. "UnitA" for the first unit and "UnitA_1" for the second one (taking into consideartion that there's no UnitA_1.pas file used)
Linker is not using an "hierarchy" of files, so each object file should be using a unique name.

It should not be a problem for compiler to do that, unless "precompiled" object files are used.
Since actual object file name collides, then it just won't work, unless object file itself is modified to produce unique names.

thanks,
Dmitry

In our previous episode, Dmitry Boyarintsev said:

What if unitaa needs recompilation, and it is not in the dir it was originally compiled in. .\some\other\place then has a different meaning.

Specially if the relative paths are short (like ..\src\ or so), there is still quite some room for clashes.

That is probably the reason it is mainly used in the DPR, there relative paths can be interpreted relative to the .dpr, and .dpr's are generally not recompiled in other directories.

Definitely, that's not the way to go. Since a unit source can rarely be adequate to the compilation environment.

thanks,
Dmitry

Technical problem:
* a unit name collision of two independent library code. Either library are using unit with the same name. The code in the conflicting units is different. Thus one library should use its own unit, the other should use its own.
Since FPC allows to specify the search path for the whole compiled program, the second library used, will be using a wrong unit (from the first library), causing either compilation to fail or wrong code generated;

Can anyone think of any logical problems with this feature:
* allow any unit (or units under specified directories) to use their own "unit-search" paths, than defined for the project. In that case if a library has its own unit, the compiler will be using the library specific unit (by finding it in the library specific search path).

From compiler point of view - it's only a matter of where to find the

source code for the unit and how to name the resulting objects and object file. (names must not conflict, in case some units of a compiler project match);
Linker, shouldn't have any issues as long as objects files were created properly;
Debugging information - no problems here, since the source file name is specified explicitly and is typically full path;

Limitations:
* two units with the same name are not allowed to be used by any other unit at the same time
uses unitA (from pathA), unitA (from pathB) - not allowed;
* RTTI collisions are not to be resolved by this feature;

thanks,
Dmitry

On Wed, Oct 30, 2013 at 4:38 PM, Dmitry Boyarintsev <

Complex...

Think this:
/project/unit1.pas
/project/StrUtils.pas
/lib/StrUtils.pas

===code===
unit unit1;
uses StrUtils; // local or Lib???
===code===

To compile the unit1.pas the compiler need to know where is StrUtils.pas and whether to use /lib/StrUtils or /project/StrUtils, right?
So, if we could to set a parameter to compiler saying: fpc -ALIAS /lib/* TheLib

Of course I invented the "-ALIAS" parameter.
So, returning to unit1, if we want to use the "local" StrUtils unit, just use the name "StrUtils". But if we want to use the Lib's StrUtils, then:

===code===
unit unit1;
uses TheLib.StrUtils;
===code===

What do you think?

Best regards,
Marcos Douglas

Hmm, let me extend your example:

/project/unit1.pas
/project/StrUtils.pas
/lib/StrUtils.pas
/lib/ExtraUtils.pas

---code---
unit ExtraUtils;

uses StrUtils; // assumed library StrUtils, not project ===code===
However, since StrUtils is present in project directory, it will be used instead, causing compilation errors.

compiling with
fpc -ALIAS /lib/* TheLib

won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils

Your thoughts?

My proposal looks like this:
-SEARCH

fpc

Causing fpc to look for units at "Libs" first when compiling "/program/unit1.pas"
No changes in any source code necessary.
With the swicth present
---code---
unit unit1

uses StrUtils; // strutils from lib
===code===

thanks,
Dmitry

Well, is more common to use just ppu files to not compile these files every compilation. So, the Lib was already compiled using your own files, all in the same directory or tree.

Your thoughts?

My propose is to compile our projects, using 3rd-party sources (libs), without names conflict.
Somebody used, eg, UnicodeUtils as an unit name in a lib... this should be Ok because the programmer do not know all lib names in the world and prefixes. So, he used a good name for your own sources.

The problem is "good name for an unit" because I also use good names! So, how can I know all unit names for all libs around the world? I can't use UnicodeUtils? FPC already use? Maybe Lazarus? I do not know. So, IMHO, we need a way to can compile these lib sources without trying to predict the future on the names of units.

This works only if you don't want use StrUtils of your project and, IMHO, this is more complex solution. You will need to tell the compiler which unit of your project that compiles using an unit in another place that uses the same unit name you already uses in your project.

The "rules" that I proposed are:
1- Sources in the same directory and/or own tree are compiled using the "real names" of units.
2- Sources in another tree are (optional) compiled using an "alias". These alias are used as a prefix to real names of units.

See. You do not create a project and put their sources out of the tree. The only reason, IMHO, you need to use sources out the main project tree is to use a lib (3rd-party).

We need dynamic namespaces.

Regards,
Marcos Douglas

The linker has to choose only 1 object file and the wrong file will be taken from the program folder.

Wrong. The search exception is created for a certain file or files under a certain directory
In example above, only /program/unit1.pas would be using StrUtils from "lib" any other file would be using StrUtils from "program".

thanks,
Dmitry

I don't know much about linker. If you saying that need to be like that, ok.

So, I can't use Lib's StrUtils and Program's StrUtils in a third unit (unit1)? Doesn't make sense.

Your thoughts about my mail prior (last part)?

Regards,
Marcos Douglas

This works only if you don't want use StrUtils of your project and,

Not each unit. The search priority can be adjusted for a directory (3d party library)

I guess, you need to define "in the same" directory. Is it "the same" to a project or to a unit?
If to "a unit" then it breaks the compiler backward compatibility. So, how to handle the following case?

/program/unit1.pas (uses TheLib.StrUtils)
/program/unit2.pas (uses StrUtils from program)
/program/StrUtils.pas
/lib/StrUtils.pas
/otherlib/otherlibunit.pas (depends on "lib" StrUtils)

So how would you "otherlibunit" to be using TheLib.StrUtils? From what I can understand (following rule #2), you need to modify "otherlibunit.pas" and change "uses StrUtils" to "uses TheLib.StrUtils"

thanks,
Dmitry

In our previous episode, Benito van der Zander said:

If you start to use short class names (by importing with *), the ambiguity is back again.

Then the John Douglas and Douglas McKey are running into the same issue. Both guys (while living on different parts of the world) created the same "douglas" namespace!

That's why most languages use domains as namespace Then you would have

net.delfire.douglas.*
org.msegui.*

and no collision

Wrong. Do not breaks the compiler backward compatibility. I said " in the same directory and/or own tree", ie, in the same directory and subdirectories. For these cases, the compiler do not need changes.

First, if you have a lib that have dependencies to another lib, you have to provide all sources together -- in the same directory or subdirectories. For this case just use the rule #1. But, if you did not provide the sources for the other lib, the user will need to define the "ALIAS" to the lib that have dependencies before compile it (package). For this case use the rule #2.

Regards,
Marcos Douglas

Exactly.

In Java, eg, if you have two imports with "*" and the two "packages" have the same class name, the compiler do not allow you declare only class name for a variable... "duplicity of names". Because this we see many sources (Java) that for a simple variable the programmer uses the full name (package and class name).

If we have "dynamic namespaces" in Pascal, we can use a big name for units (like a big path for a Java's package) but to use simple names on the code.

Best regards,
Marcos Douglas

The compiler doesn't use a unit's same directory for searching units. It is using project's file directory for searching and then any directories referenced is -Fu switch.
Thus the same list of search directories is used for any unit in the project (and that's causing the requirement to have all unit names unique per project)

First, if you have a lib that have dependencies to another lib, you

Changing the structure of a project is a big NO. For a number of reasons:
* a compiler change should never force a developer to make any major changes in the project sources or structure;
* it might be impossible to merge two different components into the same directory or sub directory, because of the conflicting file names;
* the external tools (i.e. SVN) might require two components be in a separate folders (i.e. for syncing sources);
-so I'd removing rule #1 as a solution here.
As well as rule #2, since it's not an option to change 3d party code (even just to introduce an alias reference). Don't forget that you've mentioned it earlier yourself.

thanks,
Dmitry

Of course the project's file determinate the searcher... that's what I meant before. Sorry my english.

Thus the same list of search directories is used for any unit in the project (and that's causing the requirement to have all unit names unique per project)

Yes.

There is no changes! The change is a new parameter (OPTIONAL) in the compiler... just this.

* a compiler change should never force a developer to make any major changes in the project sources or structure;

Again, I not proposed any changes in "project sources of structure".

* it might be impossible to merge two different components into the same directory or sub directory, because of the conflicting file names;

But this is already impossible today!

* the external tools (i.e. SVN) might require two components be in a separate folders (i.e. for syncing sources);

Nothing will be change to SVN, Git, whatever...

-so I'd removing rule #1 as a solution here. As well as rule #2, since it's not an option to change 3d party code (even just to introduce an alias reference). Don't forget that you've mentioned it earlier yourself.

The "rule #1" is the current rule!
Using the "rule #2" you do not need to change 3rd-party codes! This rule is to provide the programmer exactly the oposite: provide to you to use 3rd-party without change anything!

Thanks,
Marcos Douglas

so again, how should rule #2 work in the following case: program\unit1.pas
program\StrUtils.pas
program\unit2.pas
lib\StrUtils.pas
otherlib\ExtraUtils.pas

ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is not a subdirectory of lib.
unti1.pas users StrUtils.pas from "lib".
unit2.pas uses StrUtils.pas from "program"

How could I compile with structure using ALIAS?

thanks,
Dmitry

1- You need to specify the alias for compile the program (I will invent the sintaxe now):

2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is not a subdirectory of lib then the "otherlib needs to be compiled using a ALIAS:

3- If unti1.pas (program) uses StrUtils.pas from "lib". uses

  TheLib.StrUtils;

4- unit2.pas uses StrUtils.pas from "program" so, this is default:
uses StrUtils;

5- But you can define an alias for your program too:

And now:
uses

  TheApp.StrUtils;

I guess that you guess that the problem is the "otherlib" to use "lib" but you can define -- or you could -- many ALIAS for the same directory. Thus you can define your own ALIAS for "lib" and the "otherlib" (a 3rd-party package) can define another. ;-)

But, for me, doesn't any sense the otherlib does not know the lib's sources.

Best regards,
Marcos Douglas

Ah, yes, you've mentioned the necessity for two steps compilation. (compile a package first and then compile the program). Which brings the necessity for external "tools" (similar to make files) or an IDE must be smart enough to handle them.
(please note "an IDE", thus not refer erring to Lazarus specifically).

But, it might help solving the problem with object names, since a recompiled package will update object files. hmm.. or not.

But, for me, doesn't any sense the otherlib does not know the lib's sources.

Otherlib knows about "lib"s sources - it knows that there should be "StrUtils" unit.
However, it doesn't know anything about there the "StrUtils" is located, as well as it doesn't care what to do with other files of the project. It's compilers job.

In my turn, this is how I'd suggest to compile it:

program\unit1.pas (uses lib/StrUtils.pas)
program\StrUtils.pas
program\unit2.pas (uses program/StrUtils.pas)
lib\StrUtils.pas
otherlib\ExtraUtils.pas (uses lib/StrUtils.pas)

This is not required is optional.

Which brings the necessity for external "tools" (similar to make files) or an IDE must be smart enough to handle them. (please note "an IDE", thus not refer erring to Lazarus specifically).

No one compiles programs using line code options. Everybody uses a IDE or script for do it.
But I did not see what the problem because it is only a new argument for the compiler.

But, it might help solving the problem with object names, since a recompiled package will update object files. hmm.. or not.

I don't know either.

I know. When as said "Otherlib do not known about Lib" I was talking about source paths.

If you do not change the unit names, how you can use StrUtils from Lib, OtherLib and program in a same unit?
You need to have a identifier for each unit in your program. I can't read the unit1 that have "uses StrUtils" and not knowing which unit the program is refering.

Regards,
Marcos Douglas

This is not required is optional.

It is required, otherwise a wrong "StrUtils" might be used. Or let me paraphrase that, it is required to recompile it at least once.

a scripts or an IDE would need to be adjusted then. It's not a big deal, but it's a change.

Well a lib, shouldn't care about paths at all, it's compiler's job.

If you do not change the unit names, how you can use StrUtils from Lib, OtherLib and program in a same unit?

You definitely can't. I stated that as a limitation. That's not a purpose of the tag anyway, the purpose is to resolve uncontrolled unit name collisions (typically introduced by changes into a 3d party lib).

If you need to mix a code from 2 units that share the same name, you'd need to create a wrapping unit.

---code---
unit LibStrUtils

uses StrUtils;
interface
var
  procedure DoStrUtil = StrUtils.DoStrUtil;
---code---
unit Unit3;
uses StrUtils, LibStrUtils;

==code==

program\unit1.pas (uses lib/StrUtils.pas)
program\StrUtils.pas
program\unit2.pas (uses program/StrUtils.pas)
program\unit3.pas (uses program/StrUtils.pas)
program\LibStrUtils.pas (uses lib/StrUtils.pas)
lib\StrUtils.pas
otherlib\ExtraUtils.pas (uses lib/StrUtils.pas)

I meant this is not required for your own units.

As I said before, IMHO, no one compiles programs using line code options...

As I said... I agree.

If you consider my proposal, is definitely possible. IMO, doesn't exist advantages if we couldn't use two units (same name, but not same project) in the same code, at the same time.

Sorry, but this is boring.
Do you not agree that is much better propose a solution to be possible to use two -- or more -- units that have the same name but works together at the same project?

Regards,
Marcos Douglas

Marcos Douglas wrote

Sorry, but this is boring. Do you not agree that is much better propose a solution to be possible to use two -- or more -- units that have the same name but works together at the same project?

Thought process is a boring thing in nature - it supposed to exhaust brain.

I definitely disagree on benefit of that. Since it opens door not bring a unit name from a source to command-line.
You'll have a project of 10 Classes.pas and you'll define their actual name in command line:
fpc -ALIAS/graphics/classes.pas Graphics -ALIAS/audio/classes.pas audio -ALIAS/math/classes.pas

On another project the same unit, might get another alias: fpc -ALIAS/graphics/classes.pas Graph -ALIAS/audio/classes.pas sounds

So management of this kind of projects and libraries turns into a funny process.

From that point of view name spaces (as they're declared in sources)

becomes far more predictable.

But again, back to namespaces, why people couldn't use underscores "_"? The same domain pattern:
"org_douglas_marcos_classes.pas"
"org_mse_classes.pas"
With Delphi 2 the 8.3 file name limitation was removed and everybody could start growing their domain libraries.

Ok, nevermind. From what I see the biggest issue is linking and I guess RTTI (eventually)

thanks,
Dmitry

=)

But in Java we have the "same" feature. A project can point to com.company.foo.lib.MyClass but another project can use only lib.MyClass.
The packages are defined using directories. Is Java a mess too?

IMHO, my proposal is more flexible than Java because we won't have a "hard code" for path like Java does. Only the compiler will know about it, not the sources.

So management of this kind of projects and libraries turns into a funny process.

The big difference is that we are talking about our projects, not 3rd-party libraries.
You -- or the company where you works -- will decide what names will be better than others, etc.

We back again... The name collision continues!
The problem is: We do not know all names used around the world.

Ok, nevermind. From what I see the biggest issue is linking and I guess RTTI (eventually)

I don't think so. Even the names of the units could be changed "on demand" by the compiler, using the ALIAS defined before. The linker would remain the same, without changes.

Best regards,
Marcos Douglas

 The packages are defined using directories. Is Java a mess too? 

Yes, exactly, that's what makes Java package system messy. It makes refactoring (or restructurization) extremely difficult for deep package hierarchy.

On Tuesday, November 5, 2013 6:37 PM, Marcos Douglas [via Free Pascal - General] wrote:

On Mon, Nov 4, 2013 at 10:44 PM, Dmitry Boyarintsev

> The packages are defined using directories. Is Java a mess too?  Yes, exactly, that's what makes Java package system messy. It makes refactoring (or restructurization) extremely difficult for deep package hierarchy.

Java has no "package hierarchy" it's just names. It has no concept of sub-packages it's just folders.

R.

So I proposed something better. ;-)

Marcos Douglas