Re: access type referencing nested array element

[dewarr@my-dejanews.com]

In article <dale-2009981033240001@dale.ppp.cs.rmit.edu.au>,
  dale@cs.rmit.edu.au (Dale Stanbrough) wrote:
> Robert Dewar wrote...
>
> " In particular, the horrible phenomenon of people importing
>   a C style into Ada 95 is something I often see, with the
>   aliased keyword all over the place. Perfectly dreadful
>   coding style!"
>
> But of course a better style is to silenty do a 'Unrestricted_Access
> deep inside your code (a'la Gnat.Spitbol :-)
>
> Dale


Absolutely! No one is saying don't use these features at all.
You use features like this when you absolutely have to.
Certainly burying nasty uses inside an abstraction is exactly
the right usage.

There are two cases in which 'Unrestricted_Access is used
in connection with the SPITBOL interface.

First, in conjunction with the A * B notation used to
represent the A $ B notation of SPITBOL. An important part
of the design of this package is to mimic the syntax and
style of SPITBOL (note that this is similar to the use that
Brian just alluded to in the Ada port of STL).

Second, if you want to use nested procedures in connection
with immediate assignment in SPITBOL pattern structures that
are global objects, then there is no choice but to use the
'Unrestricted_Access attribute. You can of course decide for
yourself to limit the utility of the package by avoiding this
usage.

I think we all understand both the fact that procedure
pointers are very limited in Ada (though of course not
MORE limited than C/C++ where there is no nesting anyway).
We also understand the reasons for this decision.

Whether you want this limitation to apply to your use of the
SPITBOL interface is up to you of course.

But in a way this comment here gets to the crux of the
matter. The many (in my opinion silly) contributions to the
recent discussion of gotos show how easy it is for people to
make the switch from:

  "this feature is to be avoided, don't use it when there
   are equally good or better alternatives"

to

  "this feature should never be used"

That shift is almost ALWAYS a horrible mistake. If anyone
reads what I am saying about 'Access and aliased and rushes
off and puts into their coding guidelines absolute rules
against using these features, they are ignorant nitwits!
Better that you allow completely free use than hobble the
language with restrictions of this kind.

For the Ada 95 design as it stands, both the aliased keyword
and the 'Access attribute are essential ingrediants. Their
removal at this stage would badly damage the language.

If you cannot see that the previous paragraph is completely
consistent with my statements that discourage the use of
these features, you are missing a VERY important point.

In particular, the idea that you can prove that someone I am
being inconsistent by finding a use of these features in my
code is completely absurd.

It is like deciding that you don't believe that N. Wirth
understands that gotos are a bad thing because you discovered
that in his text book he uses a single goto in his code for
heapsort!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum