For a programming language that has so much right, Ada sure has oop syntax
wrong. What's more is the syntax is inconsistant with a lot of things
that
Ada got right and other languages didn't.
One of the strengths of Ada is the lack of ambiguity in code.
In Pascal you have either:
if <condition> then
statement;
or:
if <condition> then
begin
end;
or:
if <condition> then
begin
end
else
begin
end;
In C/C++/C#/Java you have a similar arrangment.
In Ada you have:
if <condition> then
end if;
or
if <condition> then
else
end if;
When you're reading Pascal/C/C++/C# or Java code you have to hunt and look
very carefully to figure out the end of an if statement. It isn't so hard
when you have a small block of code, but when you run into a bigger block
with nested for, while, and if statements it can get pretty tricky. Ada
is
much improved in that regard since the end of an if statement is clearly
marked with an "end if".
Ada is has similar constructs for loops, records, block declarations, etc.
Tagged type definitions, IMO are an abomination. If you look at Delphi
(an
object oriented version of Pascal), or C++, C# or Java, there is no
ambiguity of the scope of the entities that belong to an object.
In Ada there are rules that define the scope of an object. In my opinion
this syntax deficiency is the reason the "overriding" and "not overriding"
constructs were added to Ada 2005. They improve the situation, but you
still have to look closely to figure out which entities belong to which
objects.
Sure you can use a programming convention to always define one tagged type
per package, just like you can use a convention in C++ to always add an
"//
end if" comment after a closing bracket, but I would expect it to be a
requirement of the language.
Don't try to respond by explaining how to deal with tagged type
definitions
in Ada. I already understand and have used them. It's just that when I
work with OOP in Ada it's kind of like the drudgery of working with other
more deficient programming languages.
Perhaps the language could be enhanced to permit an alternate syntax that
clearly defines the scope of a class (or tagged type if anyone is stuck on
a
name) and a pragma to only permit the alternate syntax added?
Regards,
Steve
|
