[SOLVED] As anyone proposed the following?

[Gustavo 'Gus' Carreno]

Hey Y'All,

Before I go all Gung-ho on the compiler's issues, can any one confirm or deny if there's a proposal for this:

Code: Pascal  [Select][+][-]

1. uses
2.   SystUtils,
3.   Classes,
4.   [Common, SomeThingElse] from MyNameSpace;

Or this:

Code: Pascal  [Select][+][-]

1. uses
2.   SystUtils,
3.   Classes,
4.   MyNameSpace.*;

EDIT:
Had some time to think while preparing food, and I realised that the above suggestions, while purty, would be a nightmare for parsing( introduction of a new keyword ) and IDE completion suggestions.

Here's a revised set of options...

Code: Pascal  [Select][+][-]

1. uses
2.   SystUtils,
3.   Classes,
4.   MyNameSpace[Common, SomeOtherNS.*];
5.   // OR
6.   MyNameSpace[*];
7.   // OR
8.   MyNameSpace.[Common, SomeOtherNS.*];
9.   // OR
10.   MyNameSpace.[*];

Why: From my very limited understanding of name spaces, as they are now implemented, it's just the allowance of a period in the unit's name. So, effectively, using MyNameSpace_Common or MyNameSpace.Common, amounts to the same, right? Apart from the IDE completion when we type a period after a unit name/name space.

I would like us to have a bit more syntax sugar than just that, I guess...

Cheers,
Gus

[marcov]

You can set default namespace scopes with -FN on the cmdline or in your project. You can't do that with Bla_Common.

[Gustavo 'Gus' Carreno]

Hey Marco,

You can set default namespace scopes with -FN on the cmdline or in your project. You can't do that with Bla_Common.

While not really the answer I was waiting for, I do appreciate the time you took to drop a good tip!!!

Cheers,
Gus

[PascalDragon]

Why: From my very limited understanding of name spaces, as they are now implemented, it's just the allowance of a period in the unit's name. So, effectively, using MyNameSpace_Common or MyNameSpace.Common, amounts to the same, right? Apart from the IDE completion when we type a period after a unit name/name space.

As marcov said, with dotted unit names you can use -FNMyNameSpace and just use the units using Common instead of MyNameSpace.Common. Of course you need to be aware of potential collisions then...

I would like us to have a bit more syntax sugar than just that, I guess...

There is nothing planned for this currently or in any near future, but if anything we'd probably go the route of ISO Extended Pascal as we'll need that syntax anyway for the corresponding mode.

[marcov]

There is nothing planned for this currently or in any near future, but if anything we'd probably go the route of ISO Extended Pascal as we'll need that syntax anyway for the corresponding mode.

To import symbols from modules. Not modules from namespaces.

[Thaddy]

I think this would be something - not for the compiler - but for codetools in Lazarus. Is that what you mean?
A codetools macro would be able to add everything in a namespace to the uses clause. I may be very wrong, but I really think this is not a compiler feature.

[Gustavo 'Gus' Carreno]

Hey Marco and Thaddy,

Whenever someone attempts one of these proposals, it usually finds itself in one of these categories:

• Your tone is rude, not gonna tell you that, I'll just block you in the same tone.
• Too hard to implement.
• Would break a ton of previous code.
• Does not fit with our philosophy of where the language should evolve.
• Something else I'm forgetting.

And I totally understand all of them and the motivations that lead you peeps to respond in such a way. I do. Believe, you, me!!

If you've been noticing, I try my best to be polite and thank/praise anyone that helps me along the way, and with that in mind, I would deeply appreciate if you guys think I'm falling in any of the above categories.

Having said that, I don't think a command line switch or some tooling would, properly, answer my proposal.

And I say that because: Every language I know that has implemented name spaces has also implemented some kind of globbing( uses MyNameSpace.* ),  pick-and-choose( uses MyNameSpace.[Common, SomeOther] ) or a combination of the two( uses MyNameSpace.[Common, SomeOther.*] ).

Since I'm no compiler expert, I'm not gonna say that this is easy to add. But from a general programming view, this would just be a slight change to the part of the compiler that searches and tracks the used units. I could be wrong, and I'm sure you'll tell me that, if it's the case.

My ultimate goal is to have an extended name space usage and/or syntax. And, while I'm not sure if this is needed/wanted, I would, at least, like to hear your honest opinion about the usefulness or stupidity of it. Not pointing at a command line switch that Thaddy said would probably incur in name clashes( completely nullifying name spaces ) or sweeping it under the rug of tooling.

In the sincere hope that I'm not being rude, nor am I being completely out of bounds, I re-submit my proposal to be looked at with fresh eyes, according to what I've stated before.

Cheers,
Gus

[marcov]

And I say that because: Every language I know that has implemented name spaces has also implemented some kind of globbing( uses MyNameSpace.* ),  pick-and-choose( uses MyNameSpace.[Common, SomeOther] ) or a combination of the two( uses MyNameSpace.[Common, SomeOther.*] ).

Implementation:
Delphi namespaces are not the same as Java/C# namespaces. Namespaces are not mapped onto classpath directories or preregistered in a GAC.
Since there would be no rigid structure like a classpath where you can't find the .* with a single glob. In theory you could scan all paths and build a global map each compiler invocation, but isn't exactly elegant.

Since I'm no compiler expert, I'm not gonna say that this is easy to add. But from a general programming view, this would just be a slight change to the part of the compiler that searches and tracks the used units. I could be wrong, and I'm sure you'll tell me that, if it's the case.

It would be somewhat doable as currently there is some overall globbing to optimize searching for various extensions and case on some targets. However they mostly abort when they find their target, while a wildcard would necessary go to the end.  The whole cache system would have to roll out to all targets (if it doesn't already do), and run till the end for every wildcard. I can't 100% say how bad it would be  implementation wise.


practical use:
However my main objections is that the analogy with Java/C# doesn't hold in general.

The way our projects and package system is set up doesn't put classpath or GAC thinking central, and the "need" side of things is also not comparable as our units can already have a lot of symbols, and not meant to hold only one class, so the need for bulk inclusion is less. The FPC repository sometimes uses makefiles with an invocation per file, C style, which is horrible match for this functionality. With the current release frequency it would take a really to adapt.

My ultimate goal is to have an extended name space usage and/or syntax.

Your goal should not be porting syntax or adding features. That is cart before horse.  Your goal should be about improving scenarios.

And while I can see some minor possible examples (Some packages like JSON have a .types for base shared types, and e.g. a common or util for shared procedural functions and you include them at once) that would be quite limited for such complicated feature. Since, as said, we don't encourage one class per file.

Also trying copying features from wildly different languages rarely leads to satisfactory results. The devil is in the details.

And, while I'm not sure if this is needed/wanted, I would, at least, like to hear your honest opinion about the usefulness or stupidity of it. Not pointing at a command line switch that Thaddy said would probably incur in name clashes( completely nullifying name spaces ) or sweeping it under the rug of tooling.

See above.

In the sincere hope that I'm not being rude, nor am I being completely out of bounds, I re-submit my proposal to be looked at with fresh eyes, according to what I've stated before.

In short: finicky implementation and doubtful use. And even that after a long transition to make dotted units more central to the way things are done in projects, makefiles etc.

[Gustavo 'Gus' Carreno]

Hey Marco,

First, let me assure you that I read your reply from top to bottom!!

And, yes, I now realise that my idea is maybe a bit too close to my current use of dotted units( yes, always trying one class per file, sorry!! ) and that does not match the overall usage/philosophy.

I'll mark this thread as solved since your extensive and super well detailed answer, pretty much, ends the discussion.

For the time you had to set aside to answer my query, I cannot thank you enough. Really!!
Sometimes I get stuck in circle reasoning and it's hard to get me out. But YOU DID, with this extensive answer!!

Cheers,
Gus

[marcov]

The unit system is one of my fav language elements to think about. I once started a FreeX article to argue that it is often misunderstood and underappreciated, but didn't finish it.

[Gustavo 'Gus' Carreno]

Hey Marco,

The unit system is one of my fav language elements to think about. I once started a FreeX article to argue that it is often misunderstood and underappreciated, but didn't finish it.

I do agree !!

And it would be rather nice to read that article, if you ever finish it!!

Cheers,
Gus