Re: Hiding the value of Constants

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 7 Jul 2009 12:05:40 -0700 (PDT), Adam Beneschan wrote:

> On Jul 7, 11:48�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 7 Jul 2009 08:51:35 -0700 (PDT), Adam Beneschan wrote:
>>> I believe the reason enumeration literals are actually functions is so
>>> that you can use the same enumeration literal in more than one
>>> enumeration type and not have to worry about name conflicts.
>>
>> It is a strange explanation to me. There is no obvious reason why rules
>> about overloading named objects should be different for functions. The
>> effect is same, so the syntactic form should be same.
>>
>>> The
>>> overloading rules will allow the compiler to figure out which one is
>>> meant. �There are additional bonuses, such as being able to use an
>>> enumeration literal as the actual for a generic instantiation that
>>> expects a function. �How useful that is in practice, I don't know.
>>
>> It is indeed useful, because sometimes it is impossible to declare a ting
>> as an initialized constant. In such cases making it a function gives the
>> desired effect.
>>
>> [...]
>>
>>> If you mean that you'd like
>>> constants to be treated like static functions, so that you can
>>> overload them:
>>
>>> � � Max : constant Integer := 15;
>>> � � Max : constant Float := 15.0;
>>
>>> that's an intriguing idea.
>>
>> I think the idea is rather straightforward. But also
>>
>> � �X : Integer;
>> � �X : Float;
> 
> I'm just guessing here, but I think a big potential problem would be
> if objects of the same name were declared in different scopes.  If a
> nested subroutine has a local variable
> 
>     X : Integer;
> 
> and the body says
> 
>     X := False;
> 
> the compiler will complain.  But if the outer subroutine has its own
> local variable X of type Boolean, the compiler wouldn't catch this.
> 
> I realize that subprogram overloading can sometimes lead to the same
> kinds of situations where the compiler doesn't catch an error because
> you used the wrong parameter type, for example; and since subprograms
> can be declared implicitly, when a type is derived e.g., it might be
> hard to track down problems like that.  I suppose that the question
> is, what's the risk/benefit ratio in each case.  It could be that the
> benefits of having overloaded subprograms available outweighs the
> problems (confusion and failure to catch some errors at compile time)
> of making subprograms in an outer scope visible, while in the case of
> variables the problems outweigh the potential benefits (especially if
> nobody would really *want* to declare two variables with the same name
> and have them both visible).  Yes, that makes things inconsistent,
> which I know isn't going to please people who like to look at the
> world through theoretical eyes.  Oh, well.

Yes, but. I remember how it was programmed in FORTRAN - very few
subprograms, a lot of variables declared in. The programming style has
dramatically changed since then. Ada 2005 is a very different language. How
many variables are visible in a scope of a normal Ada program? 3-5, maybe
10 counting formal parameters. How many subprograms? Hundreds? Thousands?

Is the issue of hiding variables really actual?

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