Re: Two ideas for the next Ada Standard

[jsa@alexandria (Jon S Anthony)]

In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:

> I just state a fact of my own Ada code, it could be that I have 
> not yet learnt how to write good Ada code.

I think that is getting at it.

> In Ada, pointers are 
> distinct types which differs from C/C++,  eg:
> 
> type X1A is access X;
> type X2A is access X;
> X1P : X1A;
> X2P : X2A;
> To use X1P and X2P together often requires conversions.
> 
> X *x1p, *x2p;

Well, why would you declare TWO access types to the same designated
type, unless you really DID want tow DIFFERENT types that were in fact
distinct????  If you just want to rename for some reason then use
the renaming for types - subtype:

subtype X2A is X1A;

X1P : X1A := ...
X2P : X2A := X1P; -- No problem or conversion...
 
> In C/C++ there is only one pointer type for each object type. 
> (if we disregard const, typedefs are just syntactical sugar).

Well, if this is what you want - just do it.  Nothing prevents you
from either A) only declaring the ONE access type or B) using subtype
renamings.  The C/C++ case is just a simple subset of what you can do.


> In Ada you have to carry around both object and pointer type
> everywhere you might want to use it - if you don't you will
> often need to do some conversion.

Not if you just do what you really seem to want.


> If you write code using tagged types you often want to use dynamically
> allocated objects and hence use access values in function/procedure
> calls. When one pass 'the object' as an access argument the 'object'
> will always have mode 'in out' , it is not possible to pass the
> object with only 'in' mode.

If you are really this concerned about this why not just make the type
limited private?  Clients can't access the state (except through the
interface) and they can't assign the things.  For _clients_, it is
strictly _in_ mode.

In the body of the primitive operations defined in the interface, you
can update the individual fields (if they are not limited) of the
object designated by the parameter, but you can't assign it.  This is
rather more secure than the analog C++ where you get a small piece of
this with const T* arguments.


> So if you want to provide functions or procedures which restricts
> the update of 'the object' then you have to provide an interface
> with a mix of 'access' and 'in' modes with the following confusion
> for the user of the interaface who will need to use a mix of P1(XA)
> and P2(XA.all). It is very ugly and confusing to use such
> interfaces.

I don't understand this at all.  You're correct - it is very
confusing...


> (one could ask why one ever would use 'access constant' and I
> would reply: for the very same reasons as we have for the 'in' mode)
>
> I want the 'access constant' feature for practical reasons, not out of
> C++ notsalgia.

That sounds correct as you never had what you really seem to want in
in C++ either.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com