TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
"W. Wesley Groleau x4923" <[log in to unmask]>
Fri, 17 Jul 1998 10:10:16 -0500
"W. Wesley Groleau x4923" <[log in to unmask]>
text/plain (47 lines)
> > However, Ada has the disadvantage of not having synchronized methods.
> > ...
> Ada's protected subprograms are essentially identical to synchronized methods.

To nit-pick, would it be more precise to say "the routines within
protected types are ..." ?

> However, protected subprograms come with the added safety that a
> protected object is fully encapsulated by protected subprograms,
> whereas in Java there is nothing precluding someone from adding an
> unsynchronized method by mistake and thereby destroying the nicely
> synchronized access.
> Note that in the Ada to Java compilers, Ada's protected subprograms
> are implemented using synchronized methods, because they have
> such nearly identical semantics.

A while back in c.l.a. or gnat-chat an OOP purist complained that Ada was
bad because object.method(params); is the _only_ reasonable way to make a
call--oh, excuse me, I mean send a message :-) because it keeps the object
out of the parameter list.  I pointed out that if you _have_ to have it, a
protected type can do that.  I was immediately chastised by some Ada folks
because "protected types are intended for synchronization!"

I am not being a Java expert--yet :-)  But so far, it looks to me like a
protected type can do everything a Java class can do except inheritance by
extension.  It can even _look_ like a Java class in code.

I know protected types weren't intentionally designed for the purpose of
simulating OOPL classes, but this coincidental similarity can be
convenient when dealing with tunnel vision.  I recently talked to a
colleague who was frustrated because he is trying to adapt a lot of Ada 83
code to a new project and some other folks were telling him that they had
to rewrite something in Java or C++ because the ONLY way to meet their
requirements was to have each object have its own methods so that the
methods are guaranteed to not work on the wrong object.

First we (me and another guy) showed him how a generic package body can
have variables unique to each instantiation that can be referenced by its
subprograms without parameter passing.  But an instantiation has to have a
unique name at compile-time, which didn't fit his need.  So we showed him
how tasks and/or protected objects can also fool the OO purists.  He was
very pleased.  (If it sells, he can then go on to show them that they can
also have entries and barriers--and concurrency if present is
transparently safe.)