Frequently Asked Questions

If you have a question that isn't answered here, please submit it to Dave.

New questions and answers, May 1997

I've received a flood of questions recently as to the status of the Booch Components for Ada 95. I'd like to answer some of these questions (sort of a Mini-FAQ).

So without further ado...here's the information:

When will we see a new update?

Updates will now be coming out as fast as I can crank 'em out. Probably between once every two weeks to once a month.

The releases are being tested on the following platforms(but bear in mind that some platforms, like Aonix and GNAT, get tested before the others do):

Aonix ObjectAda 7.1 (maybe Aonix 7.0 also?)
SGI Ada 95 v1.2
OC System's PowerAda
GNAT 3.10 on all known platforms (Also works on GNAT 3.01, 3.07, but not 3.09)
Green Hills Ada 95 (not tested yet)
Intermetrics Ada 95 (not tested yet)

What documentation will be available?

All documentation for the Booch Components will be accessible via the Booch Components homepage. I intend to publish a printed book, but don't expect anything earlier than late '97 (and advice from other authors tells me even that date is unrealistic).

I also intend to publish an article in JOOP discussing the translation and design decisions.

What support will be available for the components?

RIVA Technolgies, Inc. will be providing contract support, similar to ACT's mechanism, for the Booch Components. Further, I'm more than eager to have these components bundled as third-party products with compiler vendors. We are also interested to know if any specific projects are interested in QuickTurn support. E-mail me at dweller@rivatech.com or Bryan Berthy (bryan@rivatech.com) for more information or questions.

A training course is in the works. For more details, email dweller@rivatech.com

Will the components be under GNU Public License(GPL)?

No. But the source will be free. I devised a license called the "Ada Community License"(ACL), which was originally intended to be a modification to the GPL. It will be revised to be in a simpler format, similar to other licenses like the one for Perl. In essence, you will be able to extend/modify the Booch Components with reasonable freedom, but there will always be a "Standard Distribution" which will be considered the official release. Stay tuned for more details.

What about this C++ to Ada translator? (Better known around here as YALTA, Yet Another Language Translator for Ada :-)

Well, here's the deal...it was easier to write something in Perl to leverage the lessons I've learned in translating C++ into Ada 95 (which results in about 10% _less_ code, by the way). Originally I had considered keeping this one to myself, but realized that there was no value-added. Consider the limitations:

The translator is generally designed to work with template-based components
The translator will NOT handle multiple inheritance
There's a lot of "little things" in C++ which it won't handle. This may or may not change over time. It's just a Perl script, so don't expect miracles.

For the moment, the translator is on hold. Due to the lack of $ufficient $upport, we've had to table it for a while. I've been making a little progress though, but may abandon Perl shortly to switch to ANTLR 2.0, an amazing little tool!

Why do you use pragma Assert when it's not supported by all compilers?

Well, that's a good question, and one that deserves a pretty lengthy answer. Unfortunately, I'm going to be brief.... the alternative to the following line

	pragma Assert(Curr /= null, "Attempt to Insert at NULL location");

Would be...

Added to package BC:

	Assertion_On : constant Boolean : True; -- False for assertions off

Then, in each place pragma Assert existed...

	if Assertion_On then
	   if Curr /= null then
	      Raise_Exception(Exception_Identity(Assertion_Exception),
	                      "Attempt to Insert at NULL location");
	   end if;
	end if;

That should give you the general feeling of what pragma Assert does. The utility of assertions is twofold:

Assertions give us a compact representation of an optional error-handling scheme
Assertions require no modification of source code.

pragma Assert is currently supported by Aonix ObjectAda and GNAT. There are strong (but unconfirmed :-) rumors that Rational will support the same style of assertion syntax. I think that OC Systems supports it also. I have no communication whatsoever with DDCI or RR Software, so I won't even hazard a guess. In any case, I have very strong opinions about the utility of pragma Assert, and have no desire to remove them without some very compelling arguments. Any reader is welcome to put in their comments :-)

The original FAQ

What role does Grady Booch have in this?

Grady's role is primarily advisory, but I do try to keep him informed and aware. He has the final say on the architecture of the components as they're being developed, but he has yet to tell me not to do something :-)

How are the components being released?

At the moment, the components will be released under a unique "dual-licensing" technique. For most individuals, the license will be a modified version of the Perl Artistic License, the Ada Community License, that will be less restrictive than existing GNU-based licenses. For corporations, the components will be distributed through compiler vendors that may attach special terms for maintenance of the components. This is a rather radical concept, and one that will no doubt generate controversy in the future as we work the details out. The important thing to remember is: THE SOURCE WILL REMAIN FREE.

Who is the maintainer of the components?

I will remain in that role for a while, and the mechanism to submit changes will be similar to that used for other GNU-based products. Companies with special vendor licensing will follow the guidelines set forth in their licensing terms.

Why not just use C++?

I'd rather swim naked in the Great Salt Lake with a million paper cuts on my body. After using C++ for over 8 years, I'm "Proud to Be ++ Free"

Who is Dave Weller?

Good question. Even he isn't sure :-)

What is the difference between Guarded and Synchronized Components?

Imagine a need to do "batch" processing of a list in a concurent environment. In that particular case, you might want to "lock" a component while you perform several operations on it (add, change, delete, etc.). The Guarded form permits this approach. On the downside, the Guarded form requires that you explicitly lock and unlock a component (and all the potential problems therein). For this reason, it is generally advised to use the Synchronized form unless you specifically need the features of the Guarded form.

When should I use the Dynamic Form?

I haven't done much timing on it, but the Dynamic form should generally be the default form. I'm still pondering the implementation of this one, I might come up with something really cool by the summertime.

What was the naming scheme you used for your packages and types?

Naming schemes are interesting, since people always love to argue about them. I always work from the perspective of the user that enjoys a relatively terse notation (after all, I was a C programmer long before I was an Ada guy :-). I selected long names for the packages, and short names for the types. However, I have injected enough information in the type names to allow the user to understand the form without having to know which package it came from. In general, this means the type names look like something out of the "Scrabble Game from Hell", but I find the names work out OK. Naturally, your mileage may vary :-)

[index]