|[6 earlier articles]|
|Re: By value-result vs by reference email@example.com (1994-04-24)|
|Re: By value-result vs by reference firstname.lastname@example.org (1994-04-23)|
|Re: By value-result vs by reference email@example.com (1994-04-26)|
|Re: By value-result vs by reference Theo.Norvell@comlab.oxford.ac.uk (1994-04-26)|
|Re: By value-result vs by reference firstname.lastname@example.org (1994-04-28)|
|Re: By value-result vs by reference email@example.com (1994-04-29)|
|Re: By value-result vs by reference firstname.lastname@example.org (1994-04-29)|
|Re: By value-result vs by reference email@example.com (1994-05-01)|
|From:||firstname.lastname@example.org (Robb Nebbe)|
|Organization:||Ecole Polytechnique Federale de Lausanne|
|Date:||Fri, 29 Apr 1994 09:37:01 GMT|
I have seen many people point out many problem in different languages that
all fall under the category of "the evil programmer". If a programmer
wants to break some code it can certainly find a way in pretty much any
It is sort of like the fact that you can cast away const'ness in C++; so
what, at least it's explicit.
email@example.com (Henry G. Baker) writes:
: I have two responses. First, if you are the author of the package which
: exports the limited private type (Ada's most opaque kind of abstract data
: type), and one of your customers manages to trash one of your supposedly
: protected resources, you're going to be pretty upset.
(Since the only way to do this is erroneous you're lucky the program didn't
erase your hard disk :-) This requires nesting a procedure and then
aliasing one of the parameters by passing it as a parameter to the nested
procedure and then accessing both versions of the entity. You don't write
code like that by accident.
There are easier ways to violate an abstraction if you want to.
Furthermore, if you really want to make an abstraction bomb proof you
certainly wouldn't use a scalar type (non scalar limited types are passed
by reference in Ada). In Ada9X it is a bounded error (can't erase your
hard disk any longer) and the possible results (one of which is to raise
an exception) are well defined.
: My second response is that accidently aliasing two 'in out' parameters is
: quite likely, and nearly impossible for a programmer to check for. The
: simplest example I can think of involves mathematical objects like
: bignums, short vectors (x,y,z) or small matrices.
A ADT for these types would typically have one parameter that can be
modified with the rest being constant. The problem here is that some code
might work if you used value/result and it would be incorrect if you used
by reference (if the parameter to be modified is aliased to one that is
"constant"). Maybe it would have been better to always require
I really don't think that value/result is the villan some people make
it out to be.
- Robb Nebbe
Return to the
Search the comp.compilers archives again.