Re: Default value for a record component

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:1185052757.500324.16860@22g2000hsm.googlegroups.com...
...
> without losing any of the properties of the original solution and
> without "leaking" any implementation detail to the public view. The
> idea is, of course, to compute the default value at run-time, each
> time the new object is created - but without touching the general
> "look&feel" of the original code (so that for example Controlled is
> excluded).

This is a rather stupid question, especially given the C++ example that you
give later. The closest analog to a C++ class in Ada is a controlled type.
If you want something like a C++ class, then you are likely to need to use
the tools provided in Ada to get that result.

Your question is very much like asking how to tighten a bolt that holds
together a TV cabinet, but insisting that you will only use a hammer to do
so. When someone says "use a wrench" (controlled type), you say "no, I want
to use a hammer!" (untagged record type). When someone else says "use a
screwdriver" (private part), you say "no, I want to use a hammer!". But a
hammer won't solve your problem (unless perhaps you hit yourself in the head
with it a few times! ;-)

Hinestly, I don't see any sane reason for being unwilling to use a
controlled type here. Virtually all new composite types in Ada ought to be
controlled types, because there is always some reason that you will (now or
in the future) need to have a complex initializer or finalizer. And it's
harder to retrofit that later than right away.

Moreover, the only real difference for controlled in this example is the
syntax used to declare the type; the relevant semantics is essentially
identical (how the component is accessed, objects are created, etc.) Which
means that your only real complaint is that you don't like "controlled" in
the declaration; which is about as silly as saying that Ada doesn't support
OOP because it doesn't have a "class" type.

In any case, having a type that is visible rather than a private type is
almost always a mistake. Yes, Ada allows it, but that's mainly because
methodological restrictions don't belong in a programming language (we've
dropped many of the ones originally present in Ada 83 because they get in
the way in rare but useful cases). And once you allow *anything* to leak
about the implementation of a type, there is no real value in hiding any of
it -- so Ada doesn't really try to provide such possibilities.

                                     Randy.