Trivia: Ada packages are great!

Trivia: Ada packages are great!

[Olivier Henley]

Hey,

These days, at my job, I integrate the C++ work of a colleague into a bigger product. 

Developing alone, for months, he chose convenient name for his classes.  Because they are not mandatory in C++ and because he did not need it, he did not used namespaces. Fair.

What do you think happened when moving the code into a MUCH larger C++ code base? It clashed, and a lot. It took hours to stitch things together, even adding a 'hacky halfbaked' namespace to lift the ambiguity.   

I just want to recall that in Ada being forced to choose a package name for our units is a frustration/time/clarity saver. Integrating would have taken nothing. 

Anyone arguing that enforcing explicit separation of code units is a waste of time or tutoring for bad programmers is plain wrong. 

This is one of the many reasons why Ada, in the long run, kills it. 

ohenley

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> I just want to recall that in Ada being forced to choose a package name for our units is a frustration/time/clarity saver. Integrating would have taken nothing. 

Except when the original and target package names need to differ or are in a different package hierarchies. Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers.
Which, considering your assertion that the target is a MUCH bigger codebase, would be the case almost certainly.

> Anyone arguing that enforcing explicit separation of code units is a waste of time or tutoring for bad programmers is plain wrong. 

Yes.

> This is one of the many reasons why Ada, in the long run, kills it. 

Unfortunately, no. Complex projects are complex in whatever language and code migration and integration are hard, for everybody.

Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logic and physical designs, which is not always wanted.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Björn Lundin]

On 2018-11-05 11:39, Maciej Sobczak wrote:
> Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logic and physical designs, which is not always wanted.

You can add procedures and function in separate files in Ada too
by using the 'separate' keyword.

And childpackages often help with hiearachies


-- 
--
Björn

Re: Trivia: Ada packages are great!

[Olivier Henley]

> Except when the original and target package names need to differ or are in a different package hierarchies. 

I do not get this one?

> Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers.

I disagree.

1. 99% of the time, people have their own 'utils, math etc' that does exactly what 25 other 'projects' does and NOBODY tries or even care to merge into a cohesive 'utils, math etc' package. 

2. Merging code under the same umbrella is tedious, cut, copy, paste, rename  etc but not hard. At least it removes complexity. Keeping alive duplicate type naming through 'disfigure' mechanism is another story. C++ big projects are full of that.

> Which, considering your assertion that the target is a MUCH bigger codebase, would be the case almost certainly.

hundreds++ of visual studio projects.

> Unfortunately, no. Complex projects are complex in whatever language and code migration and integration are hard, for everybody.

The problem I had would have been easily solved in Ada. The guy would have named his code cathedral something like: eg. ConsultingCompanyCathedral.AnUsualTypeName and merging would have not clashed at all because since the beginning of times the official Matrix type would have been forcefully scoped eg. OurFlagshipProduct.Whatever.AnUsualTypeName

> Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logic and physical designs, which is not always wanted.

You can argue/present it the way you want but stitching official, cast in stone, legacy types (not namespaced) that are visible everywhere + new public types declared inside classes + forward declare + anonymous namespace + partial implementation in .h files is a ****** nightmare. It is so convoluted that you end up fighting Visual Studio for the whole thing to compile under thousands of misleading errors so ... I fail to see where, practically, there is such thing as "C++ (...) makes the code migrations easier".

This I love: presenting the C++ capabilities conceptually 'sandboxed', forgetting that it exposes SO much potentially 'skewed capabilities' that facing the 'working, proper, clean context' for those capabilities to actually behave like expected is virtually impossible.

What you describe works fine with people sharing the same architectural conventions, with super good doc, with very tight knowledge of C++ exceptions to exceptions, with small code base, with same epoch code base. Once you toss some of those aspects out, to name a few, the whole thing becomes a madhouse. 

Look. In real life, companies have to hire hundreds of C++ guys to push legacy or new stuff forward. We are either morons or there is an obvious problem with the tech, yours to choose. 

Re: Trivia: Ada packages are great!

[Olivier Henley]

> Except when the original and target package names need to differ or are in a different package hierarchies. 

I do not get this one? 

> Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers. 

I disagree. 

1. 99% of the time, people have their own 'utils, math etc' that does exactly what 25 other 'projects' does and NOBODY tries or even care to merge into a cohesive 'utils, math etc' package. 

2. Merging code under the same umbrella is tedious, cut, copy, paste, rename  etc but not hard. At least it removes complexity. Keeping alive duplicate type naming through 'disfigure' mechanism is another story. C++ big projects are full of that. 

> Which, considering your assertion that the target is a MUCH bigger codebase, would be the case almost certainly. 

hundreds++ of visual studio projects. 

> Unfortunately, no. Complex projects are complex in whatever language and code migration and integration are hard, for everybody. 

The problem I had would have been easily solved in Ada. The guy would have named his code cathedral something like: eg. ConsultingCompanyCathedral.AnUsualTypeName and merging would have not clashed at all because since the beginning of times the official Matrix type would have been forcefully scoped eg. OurFlagshipProduct.Whatever.AnUsualTypeName 

> Interestingly, the feature that allows C++ namespaces to exists in multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added to the project. In comparison (and in this context), Ada couples logic and physical designs, which is not always wanted.

Merging new clashing type names AND file names with cast in stone, legacy types (not namespaced) that are visible everywhere + some of those new types declared inside classes + forward declare + heavy use of anonymous namespace + partial implementation in .h files happened to be a nightmare.

Sidenote: This I love. You are presenting the C++ capabilities conceptually 'sandboxed', eluding the fact that it exposes SO much potentially interacting 'skewed capabilities' that facing the 'working, proper, clean context' for those capabilities to actually behave like expected is rarely, very rarely, the case. 

What you describe works fine with people sharing the same architectural conventions, with super good doc, with very tight knowledge of C++ exceptions to exceptions, with small code base, with same epoch code base. Once you toss some of those aspects out, to name a few, the whole thing becomes ... IMO, a madhouse.

In real life, companies have to hire hundreds of C++ guys to push legacy and/or new stuff forward. I think we are either morons or there is an obvious problem with the tech, yours to choose. I never worked with a huge Ada code base so I cannot pinpoint typical cases gone wrong, but the fact that things are "more square" and because I build and inspect relatively big open-source Ada project from time to time it appears to me that Ada is light years more truthful to help solving a practical goal at hand.

Re: Trivia: Ada packages are great!

[Simon Wright]

Olivier Henley <olivier.henley@gmail.com> writes:

> the official Matrix type would have been forcefully scoped
> eg. OurFlagshipProduct.Whatever.AnUsualTypeName

I'd have hoped it'd be called OurFlagshipProduct.Whatever.Matrix

Re: Trivia: Ada packages are great!

[Olivier Henley]

corrections:
... the official AnUsualTypeName type would have been forcefully scoped eg. OurFlagshipProduct.Whatever.AnUsualTypeName.

Re: Trivia: Ada packages are great!

[Jeffrey R. Carter]

On 11/5/18 7:07 PM, Simon Wright wrote:
> 
> I'd have hoped it'd be called OurFlagshipProduct.Whatever.Matrix

Ourflagshipproduct being unreadable, I'd have hoped for an Ada name: 
Our_Flagship_Product.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail
18

Re: Trivia: Ada packages are great!

[Olivier Henley]

Follow up. A concrete example, one of many:

1. Atype exists in the core classes since the beginning of time.
2. Atype is redefined inside a local anonymous namespace.

This does not pass:

const Atype& var1 = _inst->getA(...);

Visual Studio gives 2 clues: 

a. Atype --> is ambiguous.
b. getA signature --> <unnamed>::AType.

Ok a bit of SO to understand how to refer to that <unnamed>::Atype locally.

i. A guy propose to wrap the anonymous namespace with another named namespace.
ii. Another propose to use 'auto'.

I tried auto, it works.

Why do I find such solutions so dubious? Am I alone? Am I crazy?

Re: Trivia: Ada packages are great!

[Olivier Henley]

On Monday, November 5, 2018 at 2:41:14 PM UTC-5, Jeffrey R. Carter wrote:
> On 11/5/18 7:07 PM, Simon Wright wrote:
> > 
> > I'd have hoped it'd be called OurFlagshipProduct.Whatever.Matrix
> 
> Ourflagshipproduct being unreadable, I'd have hoped for an Ada name: 
> Our_Flagship_Product.
> 
> -- 
> Jeff Carter
> "You tiny-brained wipers of other people's bottoms!"
> Monty Python & the Holy Grail
> 18

Sorry. Will try better next time. :)

Re: Trivia: Ada packages are great!

[Olivier Henley]

On Monday, November 5, 2018 at 2:41:14 PM UTC-5, Jeffrey R. Carter wrote:
> On 11/5/18 7:07 PM, Simon Wright wrote:
> > 
> > I'd have hoped it'd be called OurFlagshipProduct.Whatever.Matrix
> 
> Ourflagshipproduct being unreadable, I'd have hoped for an Ada name: 
> Our_Flagship_Product.
> 
> -- 
> Jeff Carter
> "You tiny-brained wipers of other people's bottoms!"
> Monty Python & the Holy Grail
> 18

shipproduct is worst. 

Re: Trivia: Ada packages are great!

[Olivier Henley]

Follow up. A concrete example, one of many: 

1. Atype exists in the core classes since the beginning of time. 
2. Atype is redefined inside a local anonymous namespace. 

This does not pass: 

const Atype& var1 = _inst->getA(...); 

Visual Studio gives 2 clues: 

a. Atype --> is ambiguous. 
b. getA signature --> <unnamed>::AType. 

Ok a bit of SO to understand how to refer to that <unnamed>::Atype locally. 

i. A guy propose to wrap the anonymous namespace with another named namespace. 
ii. Another propose to use 'auto'. 

I tried auto, it works. I find all this dubious.

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> You can add procedures and function in separate files in Ada too
> by using the 'separate' keyword.

No. You need to edit the package spec to add subprogram declarations and then edit the body to introduce separate implementation and than, if you are not yet tired already, add new file to the project. Sounds like the worst option of all.

In C++ you can "reopen" the namespace by just introducing a new file, without editing existing files related to that namespace. This allows to decouple logical and physical aspects of namespace designs.

> And childpackages often help with hiearachies

Sometimes they force hierarchies when there is no design reason for them.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Olivier Henley]

> In C++ you can "reopen" the namespace by just introducing a new file, without editing existing files related to that namespace. This allows to decouple logical and physical aspects of namespace designs.

I agree that this is convenient. Is convenience in 'architectural elaboration' a good thing? I don't think so. The body of works exist to testify of the utter mess it can produce over the years.  

But 'extension' through child package, present in the filename, is 'self documenting' in Ada. C++ namespace can be anywhere regardless of file naming... often very confusing about what is tied to what. At directory level you cannot figure out the design layout. In Ada you can get pretty much the whole picture just from that inspection. This is huge for reasoning.

Maybe enforcing the explicit merging of designs in Ada is a very good thing in the long run. It forces the team members to take decisions early and dedicate to a real solution, one that they will live with. I know this could be very heavy at time and I can easily figure why some probably ditched Ada just because of such lack of convenience --> They just want to code.   

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> But 'extension' through child package, present in the filename, is 'self documenting' in Ada. C++ namespace can be anywhere regardless of file naming... often very confusing about what is tied to what. At directory level you cannot figure out the design layout. In Ada you can get pretty much the whole picture just from that inspection. This is huge for reasoning.

Except that it is not enforced by the language. It is a (still not obligatory!) convention used with the GNAT compiler, which is the convention that I appreciate, but it is not the achievement of Ada as the language. I have seen a relatively large Ada project (several thousand files), where for historical reasons file names have been forced to be 8 characters[*], which obviously did not have anything to do with package names that they specified or implemented. Reasoning in such a mess is just impossible.

[*] See the GNAT standard package files, too. Do you know the purpose of file that has name a-tiinau.ads? Or s-atacco.ads? Can you figure out the hierarchy from such names? There are almost 700 such files in my installation, all in a single directory.

The fact that you can *voluntarily* keep order in your Ada files is great, but remember that it is not Ada vs. C++ thing. There are enough good and bad examples in both.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Björn Lundin]

On 2018-11-06 09:52, Maciej Sobczak wrote:
>> You can add procedures and function in separate files in Ada too
>> by using the 'separate' keyword.
> 
> No. You need to edit the package spec to add subprogram declarations and then edit the body to introduce separate implementation and than, if you are not yet tired already, add new file to the project. Sounds like the worst option of all.


Is that _really_ an obstacle?


-- 
--
Björn

Re: Trivia: Ada packages are great!

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:
> Reasoning in such a mess is just impossible.

Right. Having such stone age means of organizing program text shows that we
(demand) don’t ask our suppliers to produce better tools for analyzing it.
Plus, file systems are easy game for programmers wanting to show pride,
cleverness and individuality. (It works!) It also cost them less effort if
compiler vendors can outsource to filesystem handling.

Ada history shows that, by analogy, any attempt at standardizing ways of
organizing source text might attract moneymakers more than anyone. So, in
any case, files vs namespaces can be seen to provide business
opportunities.

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> > No. You need to edit the package spec to add subprogram declarations and then edit the body to introduce separate implementation and than, if you are not yet tired already, add new file to the project. Sounds like the worst option of all.
> 
> Is that _really_ an obstacle?

Well, depends on what you are trying to prove. :-)

Separate subprograms help (or obstruct) in configuration management by allowing smaller granularity of content. That is, if you need to modify a single subprogram, then only that single subprogram's file has its version changed. This is a language feature that is not needed in C and C++, because these languages do not couple logical and physical designs in the first place. That is, C and C++ do not need any special keyword to allow you to have some function in a separate file.

Separate subprograms in Ada are not helping when integrating code from a different codebase, because they do not reduce the number of files that need to be modified (and therefore versioned) when code is moved between projects. Contrary to this, C and C++ allow such moves with minimal number of file modifications - in particular, no existing file needs to be modified in order to add a new function to the existing namespace.

So, when discussing the ease of integrating code from distinct codebases (and that was the context of this discussion so far), separate is neither an obstacle, nor a feature.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Olivier Henley]

> Except that it is not enforced by the language. It is a (still not 
> obligatory!) convention used with the GNAT compiler, which is the convention 
> that I appreciate, but it is not the achievement of Ada as the language.

Oh, did not know that. Will I ever touch another compiler than GNAT?

> I have seen a relatively large Ada project (several thousand files), where for > historical reasons file names have been forced to be 8 characters[*], which 
> obviously did not have anything to do with package names that they specified 
> or implemented. Reasoning in such a mess is just impossible.

Wow ok. I feel the pain.

> [*] See the GNAT standard package files, too. Do you know the purpose of file > that has name a-tiinau.ads? Or s-atacco.ads? Can you figure out the hierarchy > from such names? There are almost 700 such files in my installation, all in a > single directory.

Did not know either. 
			

Re: Trivia: Ada packages are great!

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:

> Separate subprograms in Ada are not helping when integrating code from a
> different codebase, because they do not reduce the number of files that
> need to be modified (and therefore versioned) when code is moved between
> projects. Contrary to this, C and C++ allow such moves with minimal
> number of file modifications - in particular, no existing file needs to
> be modified in order to add a new function to the existing namespace.

Adding to a namespace in a separate file I need to modify a meta-MANIFEST
file that lists what’s in a namespace. I then only need to consult the
manifest if I need to ensure the presence of a namespace’s content in
full...

Re: Trivia: Ada packages are great!

[gautier_niouzes]

Actually some Ada compilers let you organize files as you want.
For instance the following file compiles successfully with ObjectAda 10.0 (the latest version), right now:
----8<----8<----8<----8<
package u1 is
end;
package u2 is
end;
package u3 is
end;
package u4 is
  procedure p4;
end;
package body u4 is  --  a body!
  oh: constant := 3;
  procedure p4 is begin null; end;
end;
procedure p5 is begin null; end;  --  a body!
function f6 return Integer;
----8<----8<----8<----8<

IIRC it is possible with DEC Ada as well.
Anyway, you can reorganize automatically your files with GNAT's convention using gnatchop: copy all files into one (copy *.ad* big.txt), then move big.txt in an empty sandbox, then: gnatchop big.txt. That's it...

Now, the discussion about files has overshadowed the initial point of this thread: in Ada, *everything* must be inside a unit (package, procedure or function) with a name, and *that* is an extremely useful feature compared to "flat" languages!

_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> Adding to a namespace in a separate file I need to modify a meta-MANIFEST
> file that lists what’s in a namespace.

What is a meta-MANIFEST file? Is this in the Ada or C++ context?

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> Now, the discussion about files has overshadowed the initial point of this thread: in Ada, *everything* must be inside a unit (package, procedure or function) with a name, and *that* is an extremely useful feature compared to "flat" languages!

Not exactly. It is possible to write a program as a set of procedures that do not exist in any package (starting from the program entry procedure). This is no different from having a set of free-standing functions in C or C++ at the global namespace:

-- test.adb:
with Ada.Text_IO;
with Foo;
procedure Test is
begin
    Ada.Text_IO.Put_Line ("Test");
    Foo;
end Test;

-- foo.adb:
with Ada.Text_IO;
procedure Foo is
begin
    Ada.Text_IO.Put_Line ("Foo");
end Foo;

GNAT accepts this with Test as a starting point. No specification files, no packages. Even "with Foo;" works fine without any separate spec file.
Hey, we are closer to the obfuscated Ada context!

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> Oh, did not know that. Will I ever touch another compiler than GNAT?

Depends. If your enthusiasm for Ada will make you apply for a job in the actual industry where Ada was being used since forever (like in aviation), then, yes, you will touch another compiler, and typically you will have no choice.

In any case, as you have seen with its own standard library, it's not like GNAT turns every Ada project into a programming paradise (and it's not like every C++ project is a programming hell).

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Olivier Henley]

> Depends. If your enthusiasm for Ada will make you apply for a job in the 
> actual industry where Ada was being used since forever (like in aviation), 
> then, yes, you will touch another compiler, and typically you will have no 
> choice.

I had a friend at Thales... and from what I understand, actually writing software is not for everyone. He and a bunch of others were running unit tests all day long. 

> In any case, as you have seen with its own standard library, it's not like 
> GNAT turns every Ada project into a programming paradise (and it's not like > every C++ project is a programming hell).

Maybe not but an all Ada chain of 3rd parties + grpbuild is miles ahead of VisualStudio proj or cmake or (bunch of scripts + make), all of them as an all C/C++ chain of 3rd party.

Re: Trivia: Ada packages are great!

[Olivier Henley]

> GNAT accepts this with Test as a starting point. No specification files, no 
> packages. Even "with Foo;" works fine without any separate spec file.
> Hey, we are closer to the obfuscated Ada context!

Can you do a library unit this way?

Re: Trivia: Ada packages are great!

[gautier_niouzes]

On Thursday, November 8, 2018 at 1:28:25 PM UTC+1, Maciej Sobczak wrote:
> > Now, the discussion about files has overshadowed the initial point of this thread: in Ada, *everything* must be inside a unit (package, procedure or function) with a name, and *that* is an extremely useful feature compared to "flat" languages!
> 
> Not exactly. It is possible to write a program as a set of procedures that do not exist in any package (starting from the program entry procedure).

Re-read carefully my post: it's written "*everything* must be inside a unit (package, procedure or function)", not ""*everything* must be inside a package" :-).

Re: Trivia: Ada packages are great!

[Olivier Henley]

Therefore an Ada type cannot 'dangle free' as a class can?

Re: Trivia: Ada packages are great!

[Simon Wright]

Olivier Henley <olivier.henley@gmail.com> writes:

> Therefore an Ada type cannot 'dangle free' as a class can?

Well, a class can't either. The equivalent of a class is a tagged type +
primitive subprograms declared in a package; but you can have more than
one tagged type in a package.

Re: Trivia: Ada packages are great!

[Olivier Henley]

> Well, a class can't either. The equivalent of a class is a tagged type +
> primitive subprograms declared in a package; but you can have more than
> one tagged type in a package.

The C++ class 'Curve' can exists directly inside the file curve.h, therefore a clash can happen both on file name and as a type declaration, doesn't it?

I was really asking: Therefore an Ada type cannot 'dangle free' as a C++ class can? (the C++ class 'is a user defined type')

Re: Trivia: Ada packages are great!

[gautier_niouzes]

> In any case, as you have seen with its own standard library, it's not like GNAT turns every Ada project into a programming paradise (and it's not like every C++ project is a programming hell).

Who knows, perhaps one day AdaCore will use its own tool (gnatchop, without the "-k8" option for 8.3 DOS names) and finally get the readable file names.
Hopefully the change is not too painful - like hardcoded DOS names at some places?...

Re: Trivia: Ada packages are great!

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:
> 
>> Adding to a namespace in a separate file I need to modify a meta-MANIFEST
>> file that lists what’s in a namespace.
> 
> What is a meta-MANIFEST file? Is this in the Ada or C++ context?
> 

The (C++) context is the text you have removed: I take it that neither a
file nor a single “namespace xyz {...” will provide an exhaustive answer
when asking: What unit do I need when I need all of that namespace?

Granted, this, like C# classes broken into several implementation units
will help keeping business secrets apart, for example.

Re: Trivia: Ada packages are great!

[Maciej Sobczak]

> The (C++) context is the text you have removed: I take it that neither a
> file nor a single “namespace xyz {...” will provide an exhaustive answer
> when asking: What unit do I need when I need all of that namespace?

Why would you need "all of that namespace"?
I have never had such a need, neither in C++ nor in Ada.
In fact, most often than not, I'm interested in minimizing dependencies, which means that I do *not* want most of whatever namespace/package I use.

> Granted, this, like C# classes broken into several implementation units
> will help keeping business secrets apart, for example.

Does it mean that it helps relate the implementation details?

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Trivia: Ada packages are great!

[Dmitry A. Kazakov]

On 2018-11-09 09:24, Maciej Sobczak wrote:

> Why would you need "all of that namespace"?
> I have never had such a need, neither in C++ nor in Ada.

In order to ;imit potential name conflicts (and their consequences) in 
the context of future clients.

One of big problems of Ada design is with hiding rules and use-clauses. 
Few are satisfied with them, because of the conflicts they induce and 
absence of effective means to prevent or control them.

You probably wanted to move all burden on the shoulders of the clients. 
That might be OK for C++ but unacceptable for Ada design goals, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Trivia: Ada packages are great!

[Randy Brukardt]

"Olivier Henley" <olivier.henley@gmail.com> wrote in message 
news:f309284d-146d-46be-852a-256a895962b7@googlegroups.com...
>> Well, a class can't either. The equivalent of a class is a tagged type +
>> primitive subprograms declared in a package; but you can have more than
>> one tagged type in a package.
>
> The C++ class 'Curve' can exists directly inside the file curve.h, 
> therefore a clash can happen both on file name and as a type declaration, 
> doesn't it?
>
> I was really asking: Therefore an Ada type cannot 'dangle free' as a C++ 
> class can? (the C++ class 'is a user defined type')

Right. An Ada type cannot be a compilation unit, it has to be inside of some 
compilation unit. (Which are usually packages but don't have to be.)

                          Randy.

Re: Trivia: Ada packages are great!

[Randy Brukardt]

gautier_niouzes@hotmail.com> wrote in message 
news:0c992f78-0496-4d8c-b046-fd75aae32599@googlegroups.com...
> Actually some Ada compilers let you organize files as you want.
> For instance the following file compiles successfully with ObjectAda 10.0 
> (the latest version), right now:

Note that this is an Ada requirement -- many of the ACATS tests are 
structured this way. AdaCore considers GnatChop as part of the compiler for 
the purposes of meeting the standard exactly, and in particular as part of 
processing the ACATS.

Source organization is nearly irrelevant to Ada (the language); one could 
stick all of the source into a single file and not worry about giving it 
names at all. (That's not a good idea for lots of reasons, but it's 
possible.) The language would also allow an implementation that normally 
didn't use source files at all. (But it has to have some way of processing 
the ACATS, which is necessary in order to provide portability between Ada 
compilers.)

                                             Randy.

Re: Trivia: Ada packages are great!

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:f57a37a4-9557-40d8-8f4f-1d97751fe4ea@googlegroups.com...
...
> GNAT accepts this with Test as a starting point. No
> specification files, no packages. Even "with Foo;" works fine
> without any separate spec file.
> Hey, we are closer to the obfuscated Ada context!

Sure, but the names of compilation units still have to be unique -- no 
overloading is allowed. So there still can be used to unambigiously name 
things. Ada 83 was designed carefully so that nearly(*) everything can be 
named with a full expanded name starting with the compilation unit. That was 
done in particular to help with "programming-in-the-large", and specifically 
to help with integration of large packages. There is always a way to work 
around an integration conflict without restructuring anything. (Whether 
restructuring would be a better idea is a separate issue, of course.) Of 
course, if people avoided

(*) Items in unnamed blocks and loops don't have full expanded names, but 
since these are local by nature they hardly ever are involved in an 
integration conflict. That's more of a problem for language-defined images 
(of exceptions and tags, in particular).

                                              Randy.

Re: Trivia: Ada packages are great!

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>> The (C++) context is the text you have removed: I take it that neither a
>> file nor a single “namespace xyz {...” will provide an exhaustive answer
>> when asking: What unit do I need when I need all of that namespace?
> 
> Why would you need "all of that namespace"?

Why and when? When it is my job to integrate stuff from a namespace with a
software system for delivery, for example, and the result is going to be
used by others. They have their own rules and expectations, not always
tolerating continuous (wait for) delivery of whatever I thought could be
excluded for reasons of minimization, at this time.

If they prefer convenience, I have no choice. If the namespace is tightly
coupling what is on it, I have no choice.

>> Granted, this, like C# classes broken into several implementation units
>> will help keeping business secrets apart, for example.
> 
> Does it mean that it helps relate the implementation details?

Depending on the chosen meaning of “relate”, pieces wise control over
source text creates opportunities.