Ada OOP syntax

Ada OOP syntax

[Steve]

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

Re: Ada OOP syntax

[Dmitry A. Kazakov]

On Sat, 14 Jun 2008 06:26:03 -0700, Steve wrote:

> 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.

Method is not an "entity" of an object. Note that the notation you are
advocating for is plainly inconsistent. Observe that the relation between a
method and *one* of the types of its arguments is just not 1-1.

The most notorious example when it becomes essential is multiple
dispatching operations. Operation Draw does not belong either to Device or
to Glyph.

1-1 mapping is inconsistent with operations having more than one argument
(including result). Thus any of the languages you have mention are not
OOPLs, as they necessary have types not obeying OO.

[...]
> Don't try to respond by explaining how to deal with tagged type definitions 
> in Ada.

Well, then let me explain you how to deal with OO! (:-))

> 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?

It should do exactly the reverse. Ada made such mistakes before, see
protected and task types. One consequence of these mistakes is that the
*private* part of a publicly visible protected type appears in a *public*
part of the package! This should be reversed in order treat all types
equally in OO way.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada OOP syntax

[Oliver Kellogg]

Steve wrote:

> 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.

Do you know http://mats.weber.org/thesis/Ada-Extensions.pdf ?

Not sure if it's spot on for you but well worth the read, IMHO.

--Oliver

Re: Ada OOP syntax

[Jeffrey R. Carter]

Steve wrote:
> 
> 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.
> 
> 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.

Why is it OK for the non-predefined operations of some types (integer, 
enumeration, untagged records, ...) to be separate from the type declaration, 
but not for tagged records? I'm not a fan of programming by extension (the 
correct name for OOP, which has nothing to do with object orientation), but you 
should at least be consistent in your objections.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Ada OOP syntax

[anon]

There are three thing about OPPs and Ada.

First, the concept of OOP reached it highest point after Ada 95 was out. 
And since then it has falling out of favor with most programmers that are 
not writing GUI applications.  Also, most Ada partitions are not GUI based.

Second, during the vote for Ada 2005/2007 specs the only major player 
was Adacore creators of the GNAT Ada.  But some of the major OOP 
designers such as IBM, current UNIX owner (I do not use their name), 
Apple, Sun, and etc stay way from addressing or voting on 
Ada 2005/2007 specs or about OOP.  That's one reason Adacore's GNAT 
is the only Ada 2005 package around.

Third, Microsoft which is the biggest OPP player around has never dealt 
with Ada as a language.

So, if you want OOPs in a big way you will need to use another 
language.

In <_9adnb1KYvIrW87VnZ2dnUVZ_vOdnZ2d@comcast.com>, "Steve" <nospam_steved94@comcast.net> writes:
>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
>
>
>
>

Re: Ada OOP syntax

[Dirk Heinrichs]

anon wrote:

> current UNIX owner (I do not use their name)

What's wrong with Novell?

Bye...

        Dirk

Re: Ada OOP syntax

[anon]

From the licensing agreement with Novell that Judge Kimball did not over 
turn, what I called current owner of UNIX are the ones that can sell UNIX 
to a third party, such as SUN and Microsoft.

Also at the movement Novell is playing with a couple of versions of SuSE 
Linux.


In <g3395o$uhh$1@online.de>, Dirk Heinrichs <dirk.heinrichs@online.de> writes:
>anon wrote:
>
>> current UNIX owner (I do not use their name)
>
>What's wrong with Novell?
>
>Bye...
>
>        Dirk

Re: Ada OOP syntax

[Dirk Heinrichs]

anon wrote:

> From the licensing agreement with Novell that Judge Kimball did not over
> turn, what I called current owner of UNIX are the ones that can sell UNIX
> to a third party, such as SUN and Microsoft.

Being allowed to sell something doesn't mean they own it. Novell owns Unix,
nobody else does.

> Also at the movement Novell is playing with a couple of versions of SuSE
> Linux.

???

Bye...

        Dirk
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Wanheimerstraße 68      | Web:  http://www.capgemini.com
D-40468 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net

Re: Ada OOP syntax

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

Novell owning the "copyright" does not mean they own UNIX. Just like 
GNU owning the "copyright" to GNAT does not mean they own GNAT Ada.

Actually the company I am talking about owns at least of 5%, purchased 
back in 1994/5 and anyone that owns even one party can say they own 
it. It just that Novell owns by a Judges decision the controlling interest. 
But the purchase limits some of there rights on both sides.

And the name "UNIX" is own by someone else. Even Novell admit that.

Besides the owners of the "Copyright" there is:

"Intellectual Property" of UNIX which a list of companies such as the 
old AT&T labs, SUN, SGI, IBM, NOVELL, etc own a part. And the company 
that I call the "current owners", has some "Intellectual Property" in UNIX 
as well. 

Then there are the "Patents" and that's a larger group of companies which 
include the list of "Intellectual Property" and including companies like 
Microsoft with its additions to XENIX, Exxon who owns Zilog and their 
version on UNIX. etc.

And there are others topic as well that can calm ownership to some or 
all of of any routine or language. Including the group that wrote the 
language use in creating the software.

So dude, the best way is not to argue about it.



In <1213598007.755542@xnews001>, Dirk Heinrichs <dirk.heinrichs.ext@nsn.com> writes:
>anon wrote:
>
>> From the licensing agreement with Novell that Judge Kimball did not over
>> turn, what I called current owner of UNIX are the ones that can sell UNIX
>> to a third party, such as SUN and Microsoft.
>
>Being allowed to sell something doesn't mean they own it. Novell owns Unix,
>nobody else does.
>
>> Also at the movement Novell is playing with a couple of versions of SuSE
>> Linux.
>
>???
>
>Bye...
>
>        Dirk
>-- 
>Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
>Configuration Manager   | Fax:  +49 (0)211 47068 111
>Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
>Wanheimerstraße 68      | Web:  http://www.capgemini.com
>D-40468 Düsseldorf      | ICQ#: 110037733
>GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net

Re: Ada OOP syntax

[Steve]

"Oliver Kellogg" <okellogg@users.sourceforge.net> wrote in message 
news:g313nr$uih$1@online.de...
> Steve wrote:
>
>> 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.
>
> Do you know http://mats.weber.org/thesis/Ada-Extensions.pdf ?
>
> Not sure if it's spot on for you but well worth the read, IMHO.

I haven't read the entire document yet, but plan to.  It looks very 
interesting indeed.

Regards,
Steve


>
> --Oliver
> 

Re: Ada OOP syntax

[markus034]

On Jun 17, 7:14 pm, "Steve" <nospam_steve...@comcast.net> wrote:
> "Oliver Kellogg" <okell...@users.sourceforge.net> wrote in message
>
> news:g313nr$uih$1@online.de...
>
> > Steve wrote:
>
> >> 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.
>
> > Do you knowhttp://mats.weber.org/thesis/Ada-Extensions.pdf?
>
> > Not sure if it's spot on for you but well worth the read, IMHO.
>
> I haven't read the entire document yet, but plan to.  It looks very
> interesting indeed.
>
> Regards,
> Steve
>
>
>
> > --Oliver

Especially, package types and package subtypes are very interesting.
That syntax seems to be clearer than tagged types. I don't understand
why it was rejected?

Re: Ada OOP syntax

[christoph.grein]

> Especially, package types and package subtypes are very interesting.
> That syntax seems to be clearer than tagged types. I don't understand
> why it was rejected?- Zitierten Text ausblenden -

I think because this idea would have turned Ada inside out. In Ada (as
it is), packages are just some sort of containers defining a name
space (and of course some semantic relations between types and
operations defined inside).

A package type would have been what a record is now. There would be
two different syntaxes for the same semantic thing.

Also the word subtype as used in "package subtype" has a fundamentally
different meaning. In Ada (as it is), a subtype does not introduce a
new type with perhaps some added primitive operations, it only adds a
constraint. A package subtype would have been what a derived tagged
type is now.
A derived type is not compatible with its parent type (as would imply
the word subtype in those ideas) - they are convertible only.

You might argue that those ideas whould have been more in line with
other OO languages, especially the call syntax Obj.Method (which is
now available for Ada 2005), but I think Tucker's Ada 95 is a
congenial extension of Ichbiah's Ada 83 without assaulting the sytax
and sematics.

But YMMV.

Re: Ada OOP syntax

[Dmitry A. Kazakov]

On Wed, 18 Jun 2008 00:48:22 -0700 (PDT), markus034@gmail.com wrote:

> Especially, package types and package subtypes are very interesting.
> That syntax seems to be clearer than tagged types. I don't understand
> why it was rejected?

I don't know it. But in my eyes the drawbacks of the proposal are:

1. Impure (not all types have classes, there are methods and non-methods)
2. No multiple inheritance
3. No multiple dispatch
4. Conflating classes and packages (sets of types vs. visibility)
5. Self
6. Operators (multi-methods) are clumsy and have no access to the
implementation (a consequence of 1,3,4,5) 
7. Re-dispatch (inconsistent, performance hit)
8. Entries are confused with procedures (it is unclear when and if the
queue appear)
9. It is unclear (to me) how generic (class-wide) programming is
accomplished.

Though the Ada 95 model also has some of these problems (and many others
too), yet it did not damage the language, because there seem to be ways to
fix it. Tagged types are rather an outbuilding. The proposal would be a
total rebuild (IMO on the fundament of sand).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de