The old "Object.Method" syntax debate

The old "Object.Method" syntax debate

[Marc A. Criley]

Yeah, I'm bringing this up.  Kill the thread if your eyes just rolled
up into your head %-)

The reason I'm mentioning this is because of something I just read in
Martin Carlisle, Sward, and Humphries' paper "Weaving Ada 95 into the
.Net Environment" (http://www.adapower.net/a_sharp/asharp.pdf).

While this has been available online for awhile I only now read it in
my recent issue of Ada Letters.

What caught my attention was an almost peripheral mention of modifying
GNAT to recognize the Object.Method syntax: "Ada 95 has often been
criticized for making the syntax of dispatching method calls the same
as the imperative procedure calls. [...]  We have modified the
compiler to allow the same object.method syntax [...]  We have also
performed this modification to the Windows 3.15 version of GNAT. It
required only 127 non-blank, non-comment lines of Ada code. We expect
this syntax will make it easier for students to understand
object-oriented programming. Since we also support the standard Ada 95
syntax, we still have the nicer Ada syntax for operators (x+y instead
of x."+"(y))."

I've pretty much always thought of this as a non-issue not worth all
the bandwidth that's been expended on it, since it's a matter of
syntactic sugar.

But reading that Carlisle's team changed only 127 SLOC in GNAT 3.15 to
support it, I'm thinking that if it's that cheap to change in a
compiler (and I know there's all the regression testing and LRM
updates and so on that would have to accompany such a move), then
maybe it's worth it to allow the alternate syntax and remove one of
the admittedly vacuous objections to Ada raised by the language's
critics.

Marc A. Criley

Re: The old "Object.Method" syntax debate

[David C. Hoos]

This was brought up in a forum regarding enhancements for Ada0X,
at the SIG-Ada meeting last December, and the consensus was it
should be done, so it probably will.

In defense of the charge that the objection is "vacuous," I would point
out that that notation prevents the need to fully qualify the subprogram
name (in the absence of use clauses) when invoking the subprogram
for an object which is in scope.

Having worked in the .NET environment for quite a while, it's really
nice to be able to type an object name, then the dot, and immediately
see a little pop-up-window showing all of the available operations,
and being able to select from the list instead of typing the full
subprogram name.

My current work is C#, and I haven't yet had the time to try A#, but
I hope to get around to it, soon.


"Marc A. Criley" <mcq95@earthlink.net> wrote in message
news:254c16a.0305210726.485125de@posting.google.com...
> Yeah, I'm bringing this up.  Kill the thread if your eyes just rolled
> up into your head %-)
>
> The reason I'm mentioning this is because of something I just read in
> Martin Carlisle, Sward, and Humphries' paper "Weaving Ada 95 into the
> .Net Environment" (http://www.adapower.net/a_sharp/asharp.pdf).
>
> While this has been available online for awhile I only now read it in
> my recent issue of Ada Letters.
>
> What caught my attention was an almost peripheral mention of modifying
> GNAT to recognize the Object.Method syntax: "Ada 95 has often been
> criticized for making the syntax of dispatching method calls the same
> as the imperative procedure calls. [...]  We have modified the
> compiler to allow the same object.method syntax [...]  We have also
> performed this modification to the Windows 3.15 version of GNAT. It
> required only 127 non-blank, non-comment lines of Ada code. We expect
> this syntax will make it easier for students to understand
> object-oriented programming. Since we also support the standard Ada 95
> syntax, we still have the nicer Ada syntax for operators (x+y instead
> of x."+"(y))."
>
> I've pretty much always thought of this as a non-issue not worth all
> the bandwidth that's been expended on it, since it's a matter of
> syntactic sugar.
>
> But reading that Carlisle's team changed only 127 SLOC in GNAT 3.15 to
> support it, I'm thinking that if it's that cheap to change in a
> compiler (and I know there's all the regression testing and LRM
> updates and so on that would have to accompany such a move), then
> maybe it's worth it to allow the alternate syntax and remove one of
> the admittedly vacuous objections to Ada raised by the language's
> critics.
>
> Marc A. Criley
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Jacob Sparre Andersen]

David C. Hoos wrote:

> This was brought up in a forum regarding enhancements for Ada0X,
> at the SIG-Ada meeting last December, and the consensus was it
> should be done, so it probably will.

Will the change mean that currently legal programs will have to be 
rewritten?

Jacob
-- 
"If you think Tuck has said something that is completely
  wrong, you are almost certainly missing something :-)"

Re: The old "Object.Method" syntax debate

[Robert A Duff]

Jacob Sparre Andersen <sparre@crs4.it> writes:

> Will the change mean that currently legal programs will have to be
> rewritten?

No.  The ARG is very concerned about compatibility, and would never make
a change that would cause everybody to have to rewrite their Ada
programs.

- Bob

Re: The old "Object.Method" syntax debate

[Preben Randhol]

Robert A Duff wrote:
> Jacob Sparre Andersen <sparre@crs4.it> writes:
> 
>> Will the change mean that currently legal programs will have to be
>> rewritten?
> 
> No.  The ARG is very concerned about compatibility, and would never make
> a change that would cause everybody to have to rewrite their Ada
> programs.

But how is it done?

I mean how can the compiler know that a procedure say:

   procedure Marry (Person : Man; Person2 : Woman);

should be able to call like this:

   type Him : Man;
   type Her : Woman;


   Him.Marry (Her);
   --  or
   Her.Marry (Him);

If I have understood the change suggested.

Would it not make the language ambigous?
-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Robert A Duff]

Preben Randhol <randhol+abuse@pvv.org> writes:

> But how is it done?

I don't remember.  I suggest you read the AI -- it's AI-252.

- Bob

Re: The old "Object.Method" syntax debate

[David C. Hoos]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbcnb56.996.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Robert A Duff wrote:
> > Jacob Sparre Andersen <sparre@crs4.it> writes:
> >
> >> Will the change mean that currently legal programs will have to be
> >> rewritten?
> >
> > No.  The ARG is very concerned about compatibility, and would never make
> > a change that would cause everybody to have to rewrite their Ada
> > programs.
>
> But how is it done?
>
> I mean how can the compiler know that a procedure say:
>
>    procedure Marry (Person : Man; Person2 : Woman);
>
> should be able to call like this:
>
>    type Him : Man;
>    type Her : Woman;
>
>
>    Him.Marry (Her);
>    --  or
>    Her.Marry (Him);
>
> If I have understood the change suggested.
>
> Would it not make the language ambigous?

It would not make the language ambiguous.  Since Him and Her
are objects of different types, each type would need its own
version of the Marry procedure, unless they were both derived
from a common ancestor type which had a class-wide Marry
procedure.

The two calls to such a class-wide procedure would not be
ambiguous, any more than overloaded subprograms are
ambiguous.  The different subprogram profiles disambiguate
the calls.

> -- 
> Preben Randhol                    http://www.pvv.org/~randhol/
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Preben Randhol]

David C. Hoos wrote:
> 
> It would not make the language ambiguous.  Since Him and Her
> are objects of different types, each type would need its own
> version of the Marry procedure, unless they were both derived
> from a common ancestor type which had a class-wide Marry
> procedure.

No I mean when you read it. Look at the example from the AI:


   Here is an example of use of the "object.operation" syntax:

   package P is
       type T is tagged ...
       -- implicit declaration of T'Class
       procedure Prim(X : in out T);
       procedure Classwide(X : in out T'Class; Y : Integer);
   end P;

   with P;
   package P2 is
       type T2 is new P.T with ...
       -- implicit declaration of T2'Class
       -- implicit declaration of Prim(X : in out T2);
       procedure Prim2(X : in out T2; B : Boolean);
       function Prim3(X : T2) return Float;
   end P2;

   with P2;
   procedure Main is
       Obj : P2.T2;
       CObj : P2.T2'Class := ...
   begin
       Obj.Prim;         -- call on inherited primitive
       Obj.Prim2(True);  -- call on primitive
       CObj.Prim;        -- dispatching call

Here I get confused, because looking at package P the procedures
available are: 

   Prim(X : in out T); and 
   Classwide(X : in out T'Class; Y : Integer); 

   There is no Prim; procedure

So the student will wonder why do I have to define :  

   procedure Prim(X : in out T);

and not only

   procedure Prim;
?

(Yes I know why, but if the point is to mimic C++ and other OOP languages
syntax this will confuse)

From the AI:

   Identifying both the package and the object is to some extent redundant,
   and makes object-oriented programming in Ada 95 wordier than necessary,
   and/or encourages heavy use of potentially confusing "use" clauses.
   Eliminating this redundancy would make object-oriented programming
   less-error prone, while also clarifying what object is the controlling
   object.

The last part : "..., while also clarifying what object is the controlling
object." I do not get.

how come I cannot do: 

   procedure Main is
      True_Or_Not : Boolean;
      Object : P2.T2;
   begin

      True_Or_Not.Prim2 (Object);

(I see that B is not defined in out, but if it were)

Besides if one can mix between using the old syntax and the
new type-dot-procedure syntax in the source, wouldn't that lead to quite
hard to read code?

IMHO this is messy, confusing and I neither see the motivation nor
need for it, but I guess I have gotten used to the Ada way :-) Perhaps
somebody else can show my why this is a Good Idea[tm]

Preben
-- 
"... in Ada, you can never have a buffer overflow error. Unless of
course you go very far out of your way to specifically program one
[...] most Ada programmers would consider going out of your way to
construct an Ada program that had a potential buffer overflow not
as a challenge, but as a kind of pornography." - Robert I. Eachus

Re: The old "Object.Method" syntax debate

[David C. Hoos]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbcngsq.aap.randhol+abuse@kiuk0152.chembio.ntnu.no...
> David C. Hoos wrote:
> >
> > It would not make the language ambiguous.  Since Him and Her
> > are objects of different types, each type would need its own
> > version of the Marry procedure, unless they were both derived
> > from a common ancestor type which had a class-wide Marry
> > procedure.
>
> No I mean when you read it. Look at the example from the AI:
>
>
>    Here is an example of use of the "object.operation" syntax:
>
>    package P is
>        type T is tagged ...
>        -- implicit declaration of T'Class
>        procedure Prim(X : in out T);
>        procedure Classwide(X : in out T'Class; Y : Integer);
>    end P;
>
>    with P;
>    package P2 is
>        type T2 is new P.T with ...
>        -- implicit declaration of T2'Class
>        -- implicit declaration of Prim(X : in out T2);
>        procedure Prim2(X : in out T2; B : Boolean);
>        function Prim3(X : T2) return Float;
>    end P2;
>
>    with P2;
>    procedure Main is
>        Obj : P2.T2;
>        CObj : P2.T2'Class := ...
>    begin
>        Obj.Prim;         -- call on inherited primitive
>        Obj.Prim2(True);  -- call on primitive
>        CObj.Prim;        -- dispatching call
>
> Here I get confused, because looking at package P the procedures
> available are:
>
>    Prim(X : in out T); and
>    Classwide(X : in out T'Class; Y : Integer);
>
>    There is no Prim; procedure
>
> So the student will wonder why do I have to define :
>
>    procedure Prim(X : in out T);
>
> and not only
>
>    procedure Prim;

The parameter is required to identify the "class" of which Prim is an
operation (method in classical OO-speak).  In Ada, you can have
multiple "classes" (hopefully related) within a single package, and there
is no class structure to encapsulate both fields and methods of the class.

When the fields and methods are encapsulated in a class structure, then
you have an implicit controlling parameter (e.g., named "this").  In Ada
it needs to be explicit.

In this example, X is the object whose state is changed by the operation.

>
> (Yes I know why, but if the point is to mimic C++ and other OOP languages
> syntax this will confuse)
>
> >From the AI:
>
>    Identifying both the package and the object is to some extent
redundant,
>    and makes object-oriented programming in Ada 95 wordier than necessary,
>    and/or encourages heavy use of potentially confusing "use" clauses.
>    Eliminating this redundancy would make object-oriented programming
>    less-error prone, while also clarifying what object is the controlling
>    object.
>
> The last part : "..., while also clarifying what object is the controlling
> object." I do not get.

For operations on tagged types, only one parameter controls dispatching,
and its position doesn't matter.
In the case of the example from the AI the call

CObj.Prim;

Dispatches to P.Prim or P2.Prim, depending on whether CObj is declared
as P.T'Class or P2.T2'Class;

>
> how come I cannot do:
>
>    procedure Main is
>       True_Or_Not : Boolean;
>       Object : P2.T2;
>    begin
>
>       True_Or_Not.Prim2 (Object);
>
> (I see that B is not defined in out, but if it were)
>
You cannot do what you write above because Prim2 is not an operation
of type Boolean.

If B were declared as mode in out, then you would write

Object.Prim2 (True_Or_Not);

> Besides if one can mix between using the old syntax and the
> new type-dot-procedure syntax in the source, wouldn't that lead to quite
> hard to read code?

Ada already has this notation for protected objects.

>
> IMHO this is messy, confusing and I neither see the motivation nor
> need for it, but I guess I have gotten used to the Ada way :-) Perhaps
> somebody else can show my why this is a Good Idea[tm]
>
> Preben
> -- 
> "... in Ada, you can never have a buffer overflow error. Unless of
> course you go very far out of your way to specifically program one
> [...] most Ada programmers would consider going out of your way to
> construct an Ada program that had a potential buffer overflow not
> as a challenge, but as a kind of pornography." - Robert I. Eachus
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Preben Randhol]

David C. Hoos wrote:
> 
> The parameter is required to identify the "class" of which Prim is an
> operation (method in classical OO-speak).  In Ada, you can have
> multiple "classes" (hopefully related) within a single package, and there
> is no class structure to encapsulate both fields and methods of the class.
> 
> When the fields and methods are encapsulated in a class structure, then
> you have an implicit controlling parameter (e.g., named "this").  In Ada
> it needs to be explicit.
> 
> In this example, X is the object whose state is changed by the operation.

Yes, but only because it is the first parameter of the procedure, right?

   "In Ada you model the problem space, not the solution space."
                                             -- Robert I. Eachus

Preben

Re: The old "Object.Method" syntax debate

[David C. Hoos]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbcnoqe.bde.randhol+abuse@kiuk0152.chembio.ntnu.no...
> David C. Hoos wrote:
> >
> > The parameter is required to identify the "class" of which Prim is an
> > operation (method in classical OO-speak).  In Ada, you can have
> > multiple "classes" (hopefully related) within a single package, and
there
> > is no class structure to encapsulate both fields and methods of the
class.
> >
> > When the fields and methods are encapsulated in a class structure, then
> > you have an implicit controlling parameter (e.g., named "this").  In Ada
> > it needs to be explicit.
> >
> > In this example, X is the object whose state is changed by the
operation.
>
> Yes, but only because it is the first parameter of the procedure, right?
No, it's because T is the type of which Prim is a primitive operation.

See RM95 N (28) which says:

Primitive operations.  The primitive operations of a type are the operations
(such as subprograms) declared together with the type declaration. They are
inherited by other types in the same class of types. For a tagged type, the
primitive subprograms are dispatching subprograms, providing run-time
polymorphism. A dispatching subprogram may be called with statically tagged
operands, in which case the subprogram body invoked is determined at compile
time. Alternatively, a dispatching subprogram may be called using a
dispatching
call, in which case the subprogram body invoked is determined at run time.

>
>    "In Ada you model the problem space, not the solution space."
>                                              -- Robert I. Eachus
>
> Preben
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>
>

Re: The old "Object.Method" syntax debate

[Alexander Kopilovitch]

Preben Randhol wrote:
>Perhaps somebody else can show my why this is a Good Idea[tm]

For me, this is a step in right direction -- towards "properties" of an object
(well, "properties" of a type or class) in the sense of Delphi (and then C#).


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: The old "Object.Method" syntax debate

[Preben Randhol]

David C. Hoos wrote:
> 
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
>> But how is it done?
>>
>> I mean how can the compiler know that a procedure say:
>>
>>    procedure Marry (Person : Man; Person2 : Woman);
>>
>> should be able to call like this:
>>
>>    type Him : Man;
>>    type Her : Woman;
>>
>>
>>    Him.Marry (Her);
>>    --  or
>>    Her.Marry (Him);
>>
>> If I have understood the change suggested.
>>
>> Would it not make the language ambigous?
> 
> It would not make the language ambiguous.  Since Him and Her
> are objects of different types, each type would need its own
> version of the Marry procedure, unless they were both derived
> from a common ancestor type which had a class-wide Marry
> procedure.

This means that this method will depend upon which type is defined as
the first argument. So then one need to do:

   procedure Marry (Person : in out Man; Muse : in out Woman)
   is
   begin
      --  Exchange rings and all
   end;

   procedure Marry (Muse : in out Woman; Person : in out Man);
   is
   begin
      Person.Marry (Muse);
   end;

This isn't more verbose than:

   Relations.Marry (Joe, Jane);

Besides now there is a subtle "the type owning the procedure must be listed
first" rule.

   Can one then still do something like:

   procedure Marry (Person : in out Man; Muse : in out Woman; Place : in Location)

   Joe.Marry (Place => Church, Muse => Jane);
-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Xavier Nicollin]

Robert A Duff wrote:
> 
> Jacob Sparre Andersen <sparre@crs4.it> writes:
> 
> > Will the change mean that currently legal programs will have to be
> > rewritten?
> 
> No.  The ARG is very concerned about compatibility, and would never make
> a change that would cause everybody to have to rewrite their Ada
> programs.

What about something like the following:

package A_Package is

   type A_Type is tagged record
      A_Name : Integer;
   end record;

   function A_Name (Obj : A_Type) return Integer;

end A_Package;

with A_Package; use A_Package;
...
Obj : A_Type;
N : Integer := Obj.A_Name;
               ^^^^^^^^^^

This is currently perfectly legal, but I guess it would be refused
by any compiler with the change in effect. Or would the syntax for the
function call be
   Obj.A_Name ()
?!!?

-- 
| Xavier NICOLLIN (mailto:Xavier.Nicollin@imag.fr) -- INPG (ENSIMAG)
| VERIMAG -- Centre Equation -- 2, ave. de Vignate -- F-38610 Gi�res

Re: The old "Object.Method" syntax debate

[Robert A Duff]

Xavier Nicollin <Xavier.Nicollin@imag.fr> writes:

> Robert A Duff wrote:
> > 
> > Jacob Sparre Andersen <sparre@crs4.it> writes:
> > 
> > > Will the change mean that currently legal programs will have to be
> > > rewritten?
> > 
> > No.  The ARG is very concerned about compatibility, and would never make
> > a change that would cause everybody to have to rewrite their Ada
> > programs.
> 
> What about something like the following:
> 
> package A_Package is
> 
>    type A_Type is tagged record
>       A_Name : Integer;
>    end record;
> 
>    function A_Name (Obj : A_Type) return Integer;
> 
> end A_Package;
> 
> with A_Package; use A_Package;
> ...
> Obj : A_Type;
> N : Integer := Obj.A_Name;
>                ^^^^^^^^^^
> 
> This is currently perfectly legal, but I guess it would be refused
> by any compiler with the change in effect.

No.  As I said, the ARG would never seriously consider such an
incompatible change.

>... Or would the syntax for the
> function call be
>    Obj.A_Name ()
> ?!!?

No.  AI-252 addresses this issue by using visibility rules similar to
use clauses.  See the AI if you want to know the details.  If you find
any mistakes (such as cases where the AI introduces an incompatibility),
please let the ARG know!

The ARG will tolerate incompatible changes only in extremely obscure
cases.

- Bob

Re: The old "Object.Method" syntax debate

[Xavier Nicollin]

Robert A Duff wrote:
> 
> Xavier Nicollin <Xavier.Nicollin@imag.fr> writes:
> 
> > [...]
> > package A_Package is
> >
> >    type A_Type is tagged record
> >       A_Name : Integer;
> >    end record;
> >
> >    function A_Name (Obj : A_Type) return Integer;
> >
> > end A_Package;
> >
> > with A_Package; use A_Package;
> > ...
> > Obj : A_Type;
> > N : Integer := Obj.A_Name;
> >                ^^^^^^^^^^
> >
> > This is currently perfectly legal, but I guess it would be refused
> > by any compiler with the change in effect.
> 
> No.  As I said, the ARG would never seriously consider such an
> incompatible change.

Indeed. I was only a bit confused, and had not read the AI.
 
> [...]
> 
> AI-252 addresses this issue by using visibility rules similar to
> use clauses.  See the AI if you want to know the details.

I have read it now, and it is clear: the direct visibility of the
"A_Name" component would hide the "use"-like visibility of the
"A_Name" operation, so my example would still be legal, and would
behave as before.

Sorry for wasting bandwidth!

> If you find any mistakes (such as cases where the AI introduces an
> incompatibility), please let the ARG know!

I sure would, but I doubt I will find any... Well, I found a typo in
the example, but I guess it's not worth wasting the ARG's time!

-- 
| Xavier NICOLLIN (mailto:Xavier.Nicollin@imag.fr) -- INPG (ENSIMAG)
| VERIMAG -- Centre Equation -- 2, ave. de Vignate -- F-38610 Gi�res

Re: The old "Object.Method" syntax debate

[Wesley Groleau]

One point of confusion: If the data type is
a record, and one of the fields is a pointer
to a subprogram, then in

    Obj : Rec_Type;

    ...

    Obj.Subprog ( OtherObj );

Of course, one can look back to the definition, but ...

Re: The old "Object.Method" syntax debate

[David C. Hoos]

"Jacob Sparre Andersen" <sparre@crs4.it> wrote in message
news:3ECBA778.4070909@crs4.it...
> David C. Hoos wrote:
>
> > This was brought up in a forum regarding enhancements for Ada0X,
> > at the SIG-Ada meeting last December, and the consensus was it
> > should be done, so it probably will.
>
> Will the change mean that currently legal programs will have to be
> rewritten?
No, in the spirit of Ada, backward compatibility will be maintained.
It will just allow an alternative syntax.
>
> Jacob
> -- 
> "If you think Tuck has said something that is completely
>   wrong, you are almost certainly missing something :-)"
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Preben Randhol]

David C. Hoos wrote:
> This was brought up in a forum regarding enhancements for Ada0X,
> at the SIG-Ada meeting last December, and the consensus was it
> should be done, so it probably will.
> 
> In defense of the charge that the objection is "vacuous," I would point
> out that that notation prevents the need to fully qualify the subprogram
> name (in the absence of use clauses) when invoking the subprogram
> for an object which is in scope.

How will this work?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Vinzent Hoefler]

Preben Randhol wrote:

>David C. Hoos wrote:
>
>> In defense of the charge that the objection is "vacuous," I would point
>> out that that notation prevents the need to fully qualify the subprogram
>> name (in the absence of use clauses) when invoking the subprogram
>> for an object which is in scope.
>
>How will this work?

Instead of

|My_Windows_Package.A_Window_Method (Win_Object, ...);

you then write:

|Win_Object.A_Window_Method (...);

Well, although I'm quite used to that kind of syntax, I personally
don't like that idea very much. The main reason is that it might be
confusing to see both sorts of syntaxes in a single source file one
day...


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: The old "Object.Method" syntax debate

[Preben Randhol]

Vinzent Hoefler wrote:
> 
> Well, although I'm quite used to that kind of syntax, I personally
> don't like that idea very much. The main reason is that it might be
> confusing to see both sorts of syntaxes in a single source file one
> day...

And it reduces readability IMHO. with My_Windows_Package.A_Window_Method
you know where to find the procedure.
-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[David C. Hoos]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbcnfrg.aap.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Vinzent Hoefler wrote:
> >
> > Well, although I'm quite used to that kind of syntax, I personally
> > don't like that idea very much. The main reason is that it might be
> > confusing to see both sorts of syntaxes in a single source file one
> > day...
>
> And it reduces readability IMHO. with My_Windows_Package.A_Window_Method
> you know where to find the procedure.
Well with a decent IDE -- e.g., GNAT with emacs and ada-mode, just click on
the
identifier, and go to the subprogram spec.
> -- 
> Preben Randhol                    http://www.pvv.org/~randhol/
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Preben Randhol]

David C. Hoos wrote:

> Well with a decent IDE -- e.g., GNAT with emacs and ada-mode, just
> click on the identifier, and go to the subprogram spec.

Sure, but try this on printed paper :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[tmoran]

> > Well with a decent IDE -- e.g., GNAT with emacs and ada-mode, just
> > click on the identifier, and go to the subprogram spec.
>
> Sure, but try this on printed paper :-)
   Do the 170 lines of change include changing all tools that have
Ada syntax built in?

Re: The old "Object.Method" syntax debate

[Preben Randhol]

tmoran@acm.org wrote:
>> > Well with a decent IDE -- e.g., GNAT with emacs and ada-mode, just
>> > click on the identifier, and go to the subprogram spec.
>>
>> Sure, but try this on printed paper :-)
>    Do the 170 lines of change include changing all tools that have
> Ada syntax built in?

Huh?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Dale Stanbrough]

Preben Randhol wrote:

> tmoran@acm.org wrote:
> >> > Well with a decent IDE -- e.g., GNAT with emacs and ada-mode, just
> >> > click on the identifier, and go to the subprogram spec.
> >>
> >> Sure, but try this on printed paper :-)
> >    Do the 170 lines of change include changing all tools that have
> > Ada syntax built in?
> 
> Huh?


If you write an ASIS based program (and ASIS would also have to
change) you would have to modify it to cope with the new syntax.

How many of these programs are there?

dale

Re: The old "Object.Method" syntax debate

[Ole-Hjalmar Kristensen]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Vinzent Hoefler wrote:
> > 
> > Well, although I'm quite used to that kind of syntax, I personally
> > don't like that idea very much. The main reason is that it might be
> > confusing to see both sorts of syntaxes in a single source file one
> > day...
> 
> And it reduces readability IMHO. with My_Windows_Package.A_Window_Method
> you know where to find the procedure.
> -- 
> Preben Randhol                    http://www.pvv.org/~randhol/

Excellent observation. I sometimes get the feeling that I'm in a maze
of twisted little procedures, all different, but with the same
name....

-- Ole-Hj. Kristensen

******************************************************************************
* C: You shoot yourself in the foot
*
* Ada: After correctly packaging your foot, you attempt to concurrently load
* the gun, pull the trigger, scream, and shoot yourself in the foot. When
* you try, however, you discover that your foot is of the wrong type.
*
* Algol68: you mildly deprocedure your gun, the bullet gets firmly dereferenced,
* and your foot is strongly coerced to void.
******************************************************************************

Re: The old "Object.Method" syntax debate

[Hyman Rosen]

Preben Randhol wrote:
> And it reduces readability IMHO. with My_Windows_Package.A_Window_Method
> you know where to find the procedure.

It's implicit in the nature of dispatching calls that you *don't*
know where to find the procedure, even with the current syntax. So
this is not a valid objection to the new notation.

Re: The old "Object.Method" syntax debate

[David C. Hoos]

Marc Criley looked up the AI and sent it to me.  His post should show up in
the
newsgroup when Google gets around to it.

(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00252.TXT) addresses this
issue, and appears to do so in a positive light.

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:vcn7svfjbannd6@corp.supernews.com...
> This was brought up in a forum regarding enhancements for Ada0X,
> at the SIG-Ada meeting last December, and the consensus was it
> should be done, so it probably will.
>
> In defense of the charge that the objection is "vacuous," I would point
> out that that notation prevents the need to fully qualify the subprogram
> name (in the absence of use clauses) when invoking the subprogram
> for an object which is in scope.
>
> Having worked in the .NET environment for quite a while, it's really
> nice to be able to type an object name, then the dot, and immediately
> see a little pop-up-window showing all of the available operations,
> and being able to select from the list instead of typing the full
> subprogram name.
>
> My current work is C#, and I haven't yet had the time to try A#, but
> I hope to get around to it, soon.
>
>
> "Marc A. Criley" <mcq95@earthlink.net> wrote in message
> news:254c16a.0305210726.485125de@posting.google.com...
> > Yeah, I'm bringing this up.  Kill the thread if your eyes just rolled
> > up into your head %-)
> >
> > The reason I'm mentioning this is because of something I just read in
> > Martin Carlisle, Sward, and Humphries' paper "Weaving Ada 95 into the
> > .Net Environment" (http://www.adapower.net/a_sharp/asharp.pdf).
> >
> > While this has been available online for awhile I only now read it in
> > my recent issue of Ada Letters.
> >
> > What caught my attention was an almost peripheral mention of modifying
> > GNAT to recognize the Object.Method syntax: "Ada 95 has often been
> > criticized for making the syntax of dispatching method calls the same
> > as the imperative procedure calls. [...]  We have modified the
> > compiler to allow the same object.method syntax [...]  We have also
> > performed this modification to the Windows 3.15 version of GNAT. It
> > required only 127 non-blank, non-comment lines of Ada code. We expect
> > this syntax will make it easier for students to understand
> > object-oriented programming. Since we also support the standard Ada 95
> > syntax, we still have the nicer Ada syntax for operators (x+y instead
> > of x."+"(y))."
> >
> > I've pretty much always thought of this as a non-issue not worth all
> > the bandwidth that's been expended on it, since it's a matter of
> > syntactic sugar.
> >
> > But reading that Carlisle's team changed only 127 SLOC in GNAT 3.15 to
> > support it, I'm thinking that if it's that cheap to change in a
> > compiler (and I know there's all the regression testing and LRM
> > updates and so on that would have to accompany such a move), then
> > maybe it's worth it to allow the alternate syntax and remove one of
> > the admittedly vacuous objections to Ada raised by the language's
> > critics.
> >
> > Marc A. Criley
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Warren W. Gay VE3WWG]

What I find interesting about this, was the reference
in C++ circles to allow the "Ada way" of reference, to
work around the limitations that object.method() has.

We seem to have two groups digging tunnels
underground to meet in the middle?

Probably a google of this news group could find the
pointer that posted here a few months ago.

Warren.

David C. Hoos wrote:
> This was brought up in a forum regarding enhancements for Ada0X,
> at the SIG-Ada meeting last December, and the consensus was it
> should be done, so it probably will.
> 
> In defense of the charge that the objection is "vacuous," I would point
> out that that notation prevents the need to fully qualify the subprogram
> name (in the absence of use clauses) when invoking the subprogram
> for an object which is in scope.
> 
> Having worked in the .NET environment for quite a while, it's really
> nice to be able to type an object name, then the dot, and immediately
> see a little pop-up-window showing all of the available operations,
> and being able to select from the list instead of typing the full
> subprogram name.
> 
> My current work is C#, and I haven't yet had the time to try A#, but
> I hope to get around to it, soon.
> 
> 
> "Marc A. Criley" <mcq95@earthlink.net> wrote in message
> news:254c16a.0305210726.485125de@posting.google.com...
> 
>>Yeah, I'm bringing this up.  Kill the thread if your eyes just rolled
>>up into your head %-)
>>
>>The reason I'm mentioning this is because of something I just read in
>>Martin Carlisle, Sward, and Humphries' paper "Weaving Ada 95 into the
>>.Net Environment" (http://www.adapower.net/a_sharp/asharp.pdf).
>>
>>While this has been available online for awhile I only now read it in
>>my recent issue of Ada Letters.
>>
>>What caught my attention was an almost peripheral mention of modifying
>>GNAT to recognize the Object.Method syntax: "Ada 95 has often been
>>criticized for making the syntax of dispatching method calls the same
>>as the imperative procedure calls. [...]  We have modified the
>>compiler to allow the same object.method syntax [...]  We have also
>>performed this modification to the Windows 3.15 version of GNAT. It
>>required only 127 non-blank, non-comment lines of Ada code. We expect
>>this syntax will make it easier for students to understand
>>object-oriented programming. Since we also support the standard Ada 95
>>syntax, we still have the nicer Ada syntax for operators (x+y instead
>>of x."+"(y))."
...
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: The old "Object.Method" syntax debate

[Bobby D. Bryant]

On Wed, 21 May 2003 10:47:38 -0500, David C. Hoos wrote:

> This was brought up in a forum regarding enhancements for Ada0X, at the
> SIG-Ada meeting last December, and the consensus was it should be done,
> so it probably will.
> 
> In defense of the charge that the objection is "vacuous," I would point
> out that that notation prevents the need to fully qualify the subprogram
> name (in the absence of use clauses) when invoking the subprogram for an
> object which is in scope.
> 
> Having worked in the .NET environment for quite a while, it's really
> nice to be able to type an object name, then the dot, and immediately
> see a little pop-up-window showing all of the available operations, and
> being able to select from the list instead of typing the full subprogram
> name.

IMO if the syntax is actually desirable (not a given, again IMO) then the
correct solution would be to design a next-generation language that uses
it _instead_ of what Ada uses, rather than cluttering up an already "big"
language with two independent layers of syntax.

-- 
Bobby Bryant
Austin, Texas

Re: The old "Object.Method" syntax debate

[Preben Randhol]

Bobby D. Bryant wrote:
> IMO if the syntax is actually desirable (not a given, again IMO) then the
> correct solution would be to design a next-generation language that uses
> it _instead_ of what Ada uses, rather than cluttering up an already "big"
> language with two independent layers of syntax.

I agree, except I prefer the way Ada is.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Rodrigo Garcia]

> Having worked in the .NET environment for quite a while, it's really
> nice to be able to type an object name, then the dot, and immediately
> see a little pop-up-window showing all of the available operations,
> and being able to select from the list instead of typing the full
> subprogram name.

This feature has been around long time before .NET appeared. Microsoft
people call it "IntelliSense" and many others just call it context sensitive
completion. I think it is a very nice feature, but it is just tool support.
I do not think it justifies a new syntax for Ada objects.

I would be happy if an Ada editor had something similar with package names.
Once you type the name of a package, you could have a pop-up showing all the
available operations of the package. Does anybody know of something like
that? Perhaps GPS?

I am one of those who suspect that the new syntax would add more confusion
than advantages to the language.

Rodrigo

Re: The old "Object.Method" syntax debate

[David C. Hoos]

"Rodrigo Garcia" <rodrigo.garcia@epfl.ch> wrote in message
news:3eccdf77$1@epflnews.epfl.ch...
> > Having worked in the .NET environment for quite a while, it's really
> > nice to be able to type an object name, then the dot, and immediately
> > see a little pop-up-window showing all of the available operations,
> > and being able to select from the list instead of typing the full
> > subprogram name.
>
> This feature has been around long time before .NET appeared. Microsoft
> people call it "IntelliSense" and many others just call it context
sensitive
> completion. I think it is a very nice feature, but it is just tool
support.
> I do not think it justifies a new syntax for Ada objects.

I dod not mean to suggest that the availability of "IntelliSense" justified
the
new syntax.  The new syntax would eliminate some code redundancy, as
the AI points out.
>
> I would be happy if an Ada editor had something similar with package
names.
> Once you type the name of a package, you could have a pop-up showing all
the
> available operations of the package. Does anybody know of something like
> that? Perhaps GPS?
emacs with ada-mode approaces this.  If you right-click on the name of a
package (e.g. in the with statement), you can go to the package
declaration.  If there were a pop-up-window as you suggest, it would be even
nicer if it did not limit itself to operations, but would list all package
entities
legal in the immediate editing context.
>
> I am one of those who suspect that the new syntax would add more confusion
> than advantages to the language.
As I pointed out in an earlier post, this syntax exists in Ada already for
protected types.  See, for example line 54 of phil.adb of the dining
philosophers
demonstration program that comes with GNAT:

      Room.Sticks (First_Grab).Pick_Up;

Room.Sticks (First_Grab) is the object; Pick_Up is the operation.

>
> Rodrigo
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: The old "Object.Method" syntax debate

[Rodrigo Garcia]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:vcprq15q8m344e@corp.supernews.com...
> I dod not mean to suggest that the availability of "IntelliSense"
justified
> the
> new syntax.  The new syntax would eliminate some code redundancy, as
> the AI points out.

I agree that is the point of the AI.

> > I am one of those who suspect that the new syntax would add more
confusion
> > than advantages to the language.
> As I pointed out in an earlier post, this syntax exists in Ada already for
> protected types.  See, for example line 54 of phil.adb of the dining
> philosophers
> demonstration program that comes with GNAT:
>
>       Room.Sticks (First_Grab).Pick_Up;
>
> Room.Sticks (First_Grab) is the object; Pick_Up is the operation.

Well, I heard that protected types syntax was also subject of strong
discussions and I can understand why. Nevertheless, protected types are
declared in a different way than tagged types. They already encapsulate
their subprograms and entries in their definition. Their syntax is more
similar to that used for declaring classes in mainstream OO languages so I
see natural to use the Object.Operation notation with protected types. Even
in your example you have the name of the package (Room), so they do not
"hide" the use clause.

However, primitive operation declarations of tagged types are encapsulated
in the package as with any other kind of type and the syntax is inherently
different. Why should we be able to use the new syntax only with tagged
types?

Hmm... Maybe it should be the other way round and keep the tagged type
syntax for protected types. I should propose "protected records" whose
primitive operations were run in mutual exclusion... what to do with entries
then?   :^)

Rodrigo

Re: The old "Object.Method" syntax debate

[Dmitry A. Kazakov]

Rodrigo Garcia wrote:

> "David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
> news:vcprq15q8m344e@corp.supernews.com...
>> I dod not mean to suggest that the availability of "IntelliSense"
> justified
>> the
>> new syntax.  The new syntax would eliminate some code redundancy, as
>> the AI points out.
> 
> I agree that is the point of the AI.
> 
>> > I am one of those who suspect that the new syntax would add more
> confusion
>> > than advantages to the language.
>> As I pointed out in an earlier post, this syntax exists in Ada already
>> for
>> protected types.  See, for example line 54 of phil.adb of the dining
>> philosophers
>> demonstration program that comes with GNAT:
>>
>>       Room.Sticks (First_Grab).Pick_Up;
>>
>> Room.Sticks (First_Grab) is the object; Pick_Up is the operation.
> 
> Well, I heard that protected types syntax was also subject of strong
> discussions and I can understand why.

Maybe because it is ugly? (:-))

Anyway prefix syntax exists also in the form of attributes. Strangely 
enough, that nobody has yet proposed to replace X'Length with X.Length. It 
would so OO-O-Oh! (:-))

> Nevertheless, protected types are
> declared in a different way than tagged types. They already encapsulate
> their subprograms and entries in their definition. Their syntax is more
> similar to that used for declaring classes in mainstream OO languages so I
> see natural to use the Object.Operation notation with protected types.
> Even in your example you have the name of the package (Room), so they do
> not "hide" the use clause.
> 
> However, primitive operation declarations of tagged types are encapsulated
> in the package as with any other kind of type and the syntax is inherently
> different. Why should we be able to use the new syntax only with tagged
> types?
> 
> Hmm... Maybe it should be the other way round and keep the tagged type
> syntax for protected types. I should propose "protected records" whose
> primitive operations were run in mutual exclusion... what to do with
> entries
> then?   :^)

Entries are just subprograms with queues. If an entry has several protected 
arguments then a call to it should start a protected action on both. As for 
implementation, it should be no problem in case single processor - single 
lock. For multiple processors, I do not know, anyway it will be never 
accepted. (:-))

Same for task entries. They also (unfortunately) have prefix syntax which 
prevents potentially interesting one-to-many rendezvous. And even more 
misterious entries of both a protected object and a task, sort of 
"protected rendezvous"! (:-))

--
As for prefix syntax, I would prefer an explicit renaming:

procedure Foo (X : T, Y : T);
procedure T.Foo (Z : T) renames Foo (X=>Z, Y=>with); -- (:-))

However prefix syntax is too often misleading. It is unusable for binary 
operations and multiple dispatching operations (if Ada would have them).

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: The old "Object.Method" syntax debate

[Alexander Kopilovitch]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>Anyway prefix syntax exists also in the form of attributes.

Yes, but attributes cannot be introduced by user -- sometimes programmer can 
provide an implementation of an attribute, but isn't permitted to introduce
his own attribute... this is a privilege for language designers and compiler
vendors.
(An apostrophe often is no more visible that a dot, but its upper position
in the line suggests that the following attribute somehow came from a high
authority -:) .

> Strangely 
>enough, that nobody has yet proposed to replace X'Length with X.Length. It 
>would so OO-O-Oh! (:-))

That's because the nature of attributes is so mystifying (it seems that there
are no description of what is an attribute in general, neither in ARM nor in
Rationale; and Ada books, such as Barnes's and Cohen's also do not define
precisely the general notion of attribute in Ada).


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: The old "Object.Method" syntax debate

[Robert I. Eachus]

Alexander Kopilovitch wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>>Anyway prefix syntax exists also in the form of attributes.
> 
> 
> Yes, but attributes cannot be introduced by user -- sometimes programmer can 
> provide an implementation of an attribute, but isn't permitted to introduce
> his own attribute... this is a privilege for language designers and compiler
> vendors.
> (An apostrophe often is no more visible that a dot, but its upper position
> in the line suggests that the following attribute somehow came from a high
> authority -:) .

I really don't like the idea of allowing the Object.Operation format to 
Ada.  Yeah, the compilers can usually figure it out understand it. But 
the potential confusion with component notation is going to confuse 
experienced Ada users.  (And eventually other O-O language users when 
the actually run into component references.

Since the language currently allows defining attributes which are 
procedures or functions, why not use the apostrophe notation?  Now the 
meaning of Object'Operation is clear, even when it is actually 
Object'Length or whatever.  Probably need a rule about overloading 
predefined attributes, but that shouldn't be such a big deal.  (They 
would be non-overridable declarations in scope.)

Re: The old "Object.Method" syntax debate

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Alexander Kopilovitch wrote:
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> 
>>>Anyway prefix syntax exists also in the form of attributes.
>> 
>> Yes, but attributes cannot be introduced by user -- sometimes programmer
>> can provide an implementation of an attribute, but isn't permitted to
>> introduce his own attribute... this is a privilege for language designers
>> and compiler vendors.
>> (An apostrophe often is no more visible that a dot, but its upper
>> position in the line suggests that the following attribute somehow came
>> from a high authority -:) .
> 
> I really don't like the idea of allowing the Object.Operation format to
> Ada.  Yeah, the compilers can usually figure it out understand it. But
> the potential confusion with component notation is going to confuse
> experienced Ada users.  (And eventually other O-O language users when
> the actually run into component references.

However it is also a step into abstract record types. Consider:

type Complex is private;
function Complex.Im return Real;
function Complex.Re return Real;

Here Complex appears a record type with read-only members Im and Re, being 
internally something else (a polar complex number).

> Since the language currently allows defining attributes which are
> procedures or functions, why not use the apostrophe notation?  Now the
> meaning of Object'Operation is clear, even when it is actually
> Object'Length or whatever.

To have X'Image instead of T'Image (X)? That is too good to become a 
reality. (:-))

> Probably need a rule about overloading
> predefined attributes, but that shouldn't be such a big deal.  (They
> would be non-overridable declarations in scope.)

Actually there should be an ability to declare/rename a subroutine in any of 
the following formats:

1. Functional: F (...)
2. Postfix: X.F (...)
3. Attribute: X'F (...)
4. Operational: X + Y
5. Index: X (...)
6. Aggregate: (...)
7. Constructor: X : T (...) and new T (...)

For both 2 and 3 the language should not allow other arguments be either 
dispatching or of the same type as the dedicated argument.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: The old "Object.Method" syntax debate

[John McCabe]

On Sun, 25 May 2003 11:13:08 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>To have X'Image instead of T'Image (X)? That is too good to become a 
>reality. (:-))

You mean like the GNAT X'Img attribute?


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: The old "Object.Method" syntax debate

[Warren W. Gay VE3WWG]

John McCabe wrote:
> On Sun, 25 May 2003 11:13:08 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>To have X'Image instead of T'Image (X)? That is too good to become a 
>>reality. (:-))
> 
> You mean like the GNAT X'Img attribute?
> 
> Best Regards
> John McCabe

Speaking of X'Img, which I find really handy for debugging (I try
not to leave these in final code for portability reasons), I would
love to have R'Img capability for debugging, where R is a record
or tagged record.

This would save me a great deal of time debugging.
As it is now, I usually just choose a few R.members'Img that I am
interested in, but this is tedious, and I might miss something else
interesting there.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: The old "Object.Method" syntax debate

[Dmitry A. Kazakov]

John McCabe wrote:

> On Sun, 25 May 2003 11:13:08 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>To have X'Image instead of T'Image (X)? That is too good to become a
>>reality. (:-))
> 
> You mean like the GNAT X'Img attribute?

Overridable attributes would make any explicit type specification 
superfluous in presence of an object.

[Even in Ada 83 T'Image (X) looked strange. Any possible ambiguity could be 
easily solved with a qualified expression: T'(X)'Image.]

However, overriding attributes raises an interestring question of making 
everything that could appear on the left side of an attribute a first-class 
object. To bring it to extreme what about:

   I := (array (Integer range 1..Size) of Something)'Length;  -- (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: The old "Object.Method" syntax debate

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> However, overriding attributes raises an interestring question of making
> everything that could appear on the left side of an attribute a first-class
> object.

Furthermore it allows an envolving solution to the original question:

Drop the restriction which attributes are allowed. Several attributes might
have a predefined meaning, but other than the predefined attributes might be
allowed in Ada200x.

So if you want to apply an 'object.method' syntax, do

  type object ...;
  procedure method(a : in out object; ...);
  for object'method use method;

done.

But there are more important features missing an Ada 95:
************************************************************************
Newsgroups: comp.lang.ada
Subject: AdaYY wish list from current projects
Organization: IKS GmbH Jena
Message-ID: <96ulad$r9e$1@belenus.iks-jena.de>

I have three sad problems (and a bonus problem) from my current projects.
If they can fixed by a compiler it would be very fine:

Problem 1: Pointer of component => Pointer to aggregate

  In order to mixin a generic list with head nodes not mixed into any other
  user defined structure I'd need to link not the base data but the mixin
  itself. Doing so I need to regenerate the whole aggregate pointer from
  a pointer of a component. Current (not tested) implementation:
  
with System.Address_To_Access_Conversions;

generic
   type Base is tagged limited private;
   type Mixin is tagged limited private;
package Unchecked_Upconversion is
   type Mixed is new Base with record
      mix : aliased Mixin;
   end record;
   
   package Mixin_P is new System.Address_To_Access_Conversions (Mixin);
   package Mixed_P is new System.Address_To_Access_Conversions (Mixed);
   
   Call_To_Mix_First : exception;
   function To_Base (mix : Mixin_P.Object_Pointer)
     return Mixed_P.Object_Pointer;
   function To_Mix (mixed : Mixed_P.Object_Pointer)
     return Mixin_P.Object_Pointer;
end Unchecked_Upconversion;

with System.Storage_Elements;
use System, System.Storage_Elements;

package body Unchecked_Upconversion is
   offset_found : Boolean := False;
   offset : Storage_Offset;
   
   use Mixed_P, Mixin_P;
   
   function To_Base (mix : Mixin_P.Object_Pointer)
     return Mixed_P.Object_Pointer is
   begin
      if not offset_found then
         raise Call_To_Mix_First;
      end if;
      return To_Pointer (To_Address (mix) - offset);
   end To_Base;
   
   function To_Mix (mixed : Mixed_P.Object_Pointer)
     return Mixin_P.Object_Pointer is
   begin
      if not offset_found then
	 offset := To_Address(mixed) -
	           To_Address(mixed.mix'Access);
         offset_found := true;
      end if;
      return mixed.mix'Access;
   end To_Mix;      
end Unchecked_Upconversion;

   It's clearly a workaround to fix a missing language feature. Even other
   solutions (i.e. using Base'Size) are only workarounds which may fail in
   complex situations (pragma Pack) even more likely.
   
   Of course this Conversion may return a Pointer to an invalid aggregate.
\f
Problem 2: Defining Byte_Order of record representations

   My low level networking application has to deal with low and big endian
   values on the net I want to handle with record representations clauses
   in order to get the benefits of compiler generated I/O functions.
   
   Unfortunly only the numeration of bits in the data may be specified.
   Values crossing a Storage_Element boundery can not be handled portably.
   Even worse Storage_Element'Size might not be a multiple of eight. So it's
   impossible to write portable programs.
   
   At the moment I use constructs like the following (introducing new error
   sources, because they are likely forgotten and a lot of legacy code):
      for xxx use (
         addr1 at 0 range 0 .. 7;
         addr2 at 1 range 0 .. 7;
      );
      ...
      addr : Address_Type := Unchecked_Conversion_To_Address (
                               to_uint16(x.addr1, x.addr2));
      if not addr'Valid then ...
      case addr is ...

      function to_uint16(low, high : uint8) return uint16 is
      begin
         if System.Default_Bit_Order = System.Low_Order_First then
	    return Unchecked_Conversion_To_U16 ((low, high));
	 else
	    return Unchecked_Conversion_To_U16 ((high, low));
	 end if;
      end to_uint16;
    
   I'd like to see a additional Byte_Order type and attribute to specify the
   most common byte orders indepenent from the used bit order. This attribute
   must include the conversions above in order to generate better code.
   Several CPUs does have a maschine language prefix to specify the byte and
   the bit order (in)depenty, It's only a bunch of hard wired gatters on the
   chip which should be usable from AdaYY.
\f
Problem 3: Static expressions of discriminants in record representations

   Trying to may a simple data structure like a Pascal string is not possible
   with Ada95. This is even worse in enviroments where memory mapped I/O
   contains such structures and must be handled using Atomic and Volatile
   Pragmas.
   
   It would be fine to use the following:
      type pascal_length is 0 .. 255;
      type pascal_string(len : pascal_length) is record
         data : String (1 .. len);
      end record;
      for pascal_string use record
         len  at 0 range 0 .. 7;
	 data at 1 range 0 .. 8*len - 1;
      end record;

   Additional suggestions are:
      - limit the restriction to specify discriminats at the very beginning.
      - limit the restriction to specify discriminats at statically known
        positions. Allow discriminant dependant discriminant positions.
      - limit the restriction of cycle free position specifications.
      - extend this concept to tagged records.
\f
Problem 4: Single task packages

   Several algorithms require hard work to deal with multitasking. Most of
   those algorithms consist of small and short running functions and
   procedures. On many CPUs those calls can be implemented very efficently
   using self modifying code. In order to generate such code the compiler
   has to determine which parts are single task and which might be
   interrupted. In order to ease this allow the following syntactic shugar
   constructs:
       protected package xxx ...
       protected procedure xxx ...
       protected function xxx ...
   which are similar but stronger than:
       proteced type yyy is
          procedure xxx;
       end yyy;
       y : constant yyy;   -- Singleton
       procedurce xxx is begin y.xxx; end xxx; 
************************************************************************

There is an interesting discussion on the usual archives following this
proposal.

Re: The old "Object.Method" syntax debate

[Preben Randhol]

Lutz Donnerhacke wrote:
> 
> So if you want to apply an 'object.method' syntax, do
> 
>   type object ...;
>   procedure method(a : in out object; ...);
>   for object'method use method;

   type object ...;
   procedure length(a : in out object; ...);
   for object'length use length;

:-)


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Lutz Donnerhacke wrote:
>> So if you want to apply an 'object.method' syntax, do
>>
>>   type object ...;
>>   procedure method(a : in out object; ...);
>>   for object'method use method;
> 
>    type object ...;
>    procedure length(a : in out object; ...);
>    for object'length use length;
> 
>:-)

You skipped my note on predefined attributes. Of course, you can use
functions, too.

Re: The old "Object.Method" syntax debate

[Dmitry A. Kazakov]

Lutz Donnerhacke wrote:

> * Dmitry A. Kazakov wrote:
>> However, overriding attributes raises an interestring question of making
>> everything that could appear on the left side of an attribute a
>> first-class object.
> 
> Furthermore it allows an envolving solution to the original question:
> 
> Drop the restriction which attributes are allowed. Several attributes
> might have a predefined meaning, but other than the predefined attributes
> might be allowed in Ada200x.
> 
> So if you want to apply an 'object.method' syntax, do
> 
>   type object ...;
>   procedure method(a : in out object; ...);
>   for object'method use method;

Or better

object'method renames method;

Now if you do not want to expose method, you would need a sort of private 
renaming:

   object'method renames private;
private
   procedure method(a : in out object; ...);
   object'method renames method;


> But there are more important features missing an Ada 95:
> ************************************************************************
> Newsgroups: comp.lang.ada
> Subject: AdaYY wish list from current projects
> Organization: IKS GmbH Jena
> Message-ID: <96ulad$r9e$1@belenus.iks-jena.de>
> 
> I have three sad problems (and a bonus problem) from my current projects.
> If they can fixed by a compiler it would be very fine:
> 
> Problem 1: Pointer of component => Pointer to aggregate

Solved with MI = Class-wide pointer -> Dispatch

> Problem 2: Defining Byte_Order of record representations

I didn'tunderstand this. Why Value := Low + High * 256 is unsufficient. I 
never had problems in passing integers over sockets. But I admit, I know no 
solution for an efficient dealing with floats (in binary format).

> Problem 3: Static expressions of discriminants in record representations

Yes it is a pain. But the major problem as I see it is breaking separation 
of implementation and interface by discriminants. Clearly there has to be 
public and private (implementational) discriminants. Later deduced from 
former. With true constructors this could be solved.

> Problem 4: Single task packages

My problem is that task and protected types are not tagged and so fall out 
of type hierarchy. Then I would like to have "accept"-procedures (with task 
object as a parameter) in addition to the accept statement.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: The old "Object.Method" syntax debate

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> Lutz Donnerhacke wrote:
>>   procedure method(a : in out object; ...);
>>   for object'method use method;
> 
> Or better
> 
> object'method renames method;

I do not like to introduce just another syntax for attribute definitions.

>> Problem 1: Pointer of component => Pointer to aggregate
> 
> Solved with MI = Class-wide pointer -> Dispatch

I do not have tagged data types. Due to hardware design requirements I can
not have tagged data types.

>> Problem 2: Defining Byte_Order of record representations
>
> I didn'tunderstand this. Why Value := Low + High * 256 is unsufficient. I
> never had problems in passing integers over sockets. But I admit, I know no
> solution for an efficient dealing with floats (in binary format).

A portable program using record representation clauses is not possible to
write in Ada95 (besides you restrict yourself to boolean components only).
If you like to show me something other, please consider a 6bit bytesize and
36bit wordsize processor ...

The portable solution for complex data types is writing distinct parsing and
constructing routines. This is inefficient and can not applied to memory
mapped data. I do not accept this limitation of Ada95.

>> Problem 3: Static expressions of discriminants in record representations
>
> Yes it is a pain. But the major problem as I see it is breaking separation
> of implementation and interface by discriminants.

I do not see any seperation by declarative programming.

> Clearly there has to be public and private (implementational)
> discriminants.

No. An external (memory mapped) data structure has only public components.
Representation issues does no deal with private and public differences either.

> With true constructors this could be solved.

Initialisation routines exists and do not solve the problem. Constructor
routines do not solve the memory mapping either. So what?

Re: The old "Object.Method" syntax debate

[Randy Brukardt]

Lutz Donnerhacke wrote in message ...
>* Dmitry A. Kazakov wrote:
>> Lutz Donnerhacke wrote:
>>> Problem 1: Pointer of component => Pointer to aggregate
>>
>> Solved with MI = Class-wide pointer -> Dispatch
>
>I do not have tagged data types. Due to hardware design requirements I
can
>not have tagged data types.


Speaking for myself, (and not the ARG!), I have a very big problem with
people who say that we should change the language, because they cannot
(or are unwilling) to use the features already in the language that can
solve the problem.

That is especially true in the case of tagged types and finalization. We
see a lot of proposals which essentially are providing some of the
functionality of these features without actually using them. The problem
is that such things complicate the language without adding anything for
the majority of users. Moreover, such proposed features typcially have
similar overhead and implementations to the existing features. So, if
the requestor has a valid reason for not using the feature (such as too
much overhead), they probably could use the proposed feature either.
OTOH, if the requestor's reason is just FUD (fear, uncertainty,
doubt) -- which I see a lot in embedded Ada programs -- it would be a
lot cheaper for everyone to educate them to eliminate the FUD than to
change the language with the associated costs for everyone.

Of course you can have tagged data types. You may not be able to have
them in your hardware interface packages, but certainly you can use them
in the bulk of your code. Why not? You can give rep. clauses on them;
you can even lay out the type such that everything except the tag
matches the hardware representation. (That is what we did in Claw for
the bitmap types. That allowed us to cleanly model the numerous
representations without dozens of case statements.)

It's annoying that SPARK doesn't support dynamic dispatching, since it
is relatively easy to describe the requirements (essentially that any
overridden potentially dispatching routine have the same set of
pre-conditions and post-conditions as its parent). But the requirements
of SPARK have little to do with the needs of the next generation of Ada
programmers.

               Randy.

Re: The old "Object.Method" syntax debate

[Lutz Donnerhacke]

* Randy Brukardt wrote:
> Lutz Donnerhacke wrote in message ...
>>* Dmitry A. Kazakov wrote:
>>> Lutz Donnerhacke wrote:
>>>> Problem 1: Pointer of component => Pointer to aggregate
>>>
>>> Solved with MI = Class-wide pointer -> Dispatch
>>
>>I do not have tagged data types. Due to hardware design requirements I can
>>not have tagged data types.
>
> Speaking for myself, (and not the ARG!), I have a very big problem with
> people who say that we should change the language, because they cannot
> (or are unwilling) to use the features already in the language that can
> solve the problem.

I solved the problem within the current language. This code is unrealiable
and part of the reasoning to suggest the new feature. You may discard the
existing code and complain about the missing one. It does not bother me.

> That is especially true in the case of tagged types and finalization. We
> see a lot of proposals which essentially are providing some of the
> functionality of these features without actually using them. The problem
> is that such things complicate the language without adding anything for
> the majority of users. Moreover, such proposed features typcially have
> similar overhead and implementations to the existing features. So, if
> the requestor has a valid reason for not using the feature (such as too
> much overhead), they probably could use the proposed feature either.

The reasoning behind the requested feature is simple: Only the compiler
knows how the data types are layouted on a given instantiation. There is no
way to determine the layout without very dirty tricks, I do not want to
apply without any need. Currently I use those tricks. YMMV.

> OTOH, if the requestor's reason is just FUD (fear, uncertainty,
> doubt) -- which I see a lot in embedded Ada programs -- it would be a
> lot cheaper for everyone to educate them to eliminate the FUD than to
> change the language with the associated costs for everyone.

FUD is not on my boots, isn't it?

> Of course you can have tagged data types. You may not be able to have
> them in your hardware interface packages, but certainly you can use them
> in the bulk of your code. Why not? You can give rep. clauses on them;
> you can even lay out the type such that everything except the tag
> matches the hardware representation. (That is what we did in Claw for
> the bitmap types. That allowed us to cleanly model the numerous
> representations without dozens of case statements.)

Of course I can do this. But for what purpose? It would be much more
efficient to write an inferfacing package copying the exact memory layout
from a specialized data type to the tagged one without representation clauses.

> of SPARK have little to do with the needs of the next generation of Ada
> programmers.

I do not talk about SPARK. Not here.

Re: The old "Object.Method" syntax debate

[Dmitry A. Kazakov]

Lutz Donnerhacke wrote:

> * Dmitry A. Kazakov wrote:
>> Lutz Donnerhacke wrote:
>>>   procedure method(a : in out object; ...);
>>>   for object'method use method;
>> 
>> Or better
>> 
>> object'method renames method;
> 
> I do not like to introduce just another syntax for attribute definitions.
> 
>>> Problem 1: Pointer of component => Pointer to aggregate
>> 
>> Solved with MI = Class-wide pointer -> Dispatch
> 
> I do not have tagged data types. Due to hardware design requirements I can
> not have tagged data types.

It is a strange view. In my present embedded project I am widely using 
tagged types (it is not a 16-bit controller, though). I do not think that 
any kludge I might invent would outperform the compiler generated code.

>>> Problem 2: Defining Byte_Order of record representations
>>
>> I didn'tunderstand this. Why Value := Low + High * 256 is unsufficient. I
>> never had problems in passing integers over sockets. But I admit, I know
>> no solution for an efficient dealing with floats (in binary format).
> 
> A portable program using record representation clauses is not possible to
> write in Ada95 (besides you restrict yourself to boolean components only).
> If you like to show me something other, please consider a 6bit bytesize
> and 36bit wordsize processor ...
> 
> The portable solution for complex data types is writing distinct parsing
> and constructing routines. This is inefficient and can not applied to
> memory mapped data. I do not accept this limitation of Ada95.

It seems that you consider Ada <-> Ada communication, which is a minor case. 
My problem is Ada <-> Something communication. It is a delusion to hope 
that any sort of representation clause might exclude parsing (do not forget 
protocal error detection). Did you see proprietary CAN-bus protocols? You 
would need rather Freud than Ada to deal with that! (:-))

>>> Problem 3: Static expressions of discriminants in record representations
>>
>> Yes it is a pain. But the major problem as I see it is breaking
>> separation of implementation and interface by discriminants.
> 
> I do not see any seperation by declarative programming.
> 
>> Clearly there has to be public and private (implementational)
>> discriminants.
> 
> No. An external (memory mapped) data structure has only public components.
> Representation issues does no deal with private and public differences
> either.

I suppose you will first copy an object from the dual-ported RAM to 
conventinal RAM before dealing with the data. Those objects better have 
different representation.

>> With true constructors this could be solved.
> 
> Initialisation routines exists and do not solve the problem. Constructor
> routines do not solve the memory mapping either. So what?

If I can construct in-place, I am free to chose a type representation at 
will (a bit array if things are really bad). The price is a slover data 
access, of course.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: The old "Object.Method" syntax debate

[Alexander Kopilovitch]

Robert I. Eachus wrote:
>I really don't like the idea of allowing the Object.Operation format to
>Ada.  Yeah, the compilers can usually figure it out understand it. But
>the potential confusion with component notation is going to confuse
>experienced Ada users.  (And eventually other O-O language users when
>the actually run into component references.

I agree that there may be those troubles with this notation, but there are
significant gains also. Potential confusion with component is one side of
this change, but another side is abstraction step for the concept of component.
In other words, there are cases where it is significant to know that a member
of composite type is really represented by corresponding data element; but
there are plenty of cases where flexibility is more desirable, that is, our
layer should not depend on whether that member actually has consolidated
reprepsentation in memory or it is computed on demand.
  Real problem with this "object notation" for operations in Ada is that there
is no clear understanding where this notation is for good and where it is for
evil. AI-252 mentions "controlling" object, and yes, there are plenty of cases
where we really have some controlling object, and in those cases that "object
notation" often are justified (after all, in such cases this notation actually
carries useful information, explicitly pointing out at the controlling object).
But unfortunately there is very big "grey zone" where controlling objects are
doubtful, and there are many cases without natural controlling objects at all.

>Since the language currently allows defining attributes which are
>procedures or functions, why not use the apostrophe notation?  Now the
>meaning of Object'Operation is clear, even when it is actually
>Object'Length or whatever.  Probably need a rule about overloading
>predefined attributes, but that shouldn't be such a big deal.  (They
>would be non-overridable declarations in scope.)

I think that it would be wrong to take away that exclusive privilege --
to introduce attributes -- from the language designers and compiler vendors.
The name space for attributes is too important language resource, it should
not be given out freely for general use.
  How about another character instead of apostrophe (or dot) for user-defined
attributes? For example, there is quite popular # (read "join" for this purpose):
 Object#Operation 
("controlling object" somehow associates with "base" -:)


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: The old "Object.Method" syntax debate

[John McCabe]

On 27 May 2003 20:02:21 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>I agree that there may be those troubles with this notation, but there are
>significant gains also. Potential confusion with component is one side of
>this change, but another side is abstraction step for the concept of component.
>In other words, there are cases where it is significant to know that a member
>of composite type is really represented by corresponding data element; but
>there are plenty of cases where flexibility is more desirable, that is, our
>layer should not depend on whether that member actually has consolidated
>reprepsentation in memory or it is computed on demand.

That is an interesting point and, I believe, directly analogous to the
Ada concept of using the same type of parentheses for array acceses
and function parameters.

>  Real problem with this "object notation" for operations in Ada is that there
>is no clear understanding where this notation is for good and where it is for
>evil. AI-252 mentions "controlling" object, and yes, there are plenty of cases
>where we really have some controlling object, and in those cases that "object
>notation" often are justified (after all, in such cases this notation actually
>carries useful information, explicitly pointing out at the controlling object).
>But unfortunately there is very big "grey zone" where controlling objects are
>doubtful, and there are many cases without natural controlling objects at all.

To be honest I've always had a little difficulty with controlling
objects and the Ada 95 syntax. I think this may be because I was
trying to get a feel for C++/Java/VB at around the same time as I was
learning to use Ada 95 and the object.operation syntax seemed so
obvious and simple to me.

>I think that it would be wrong to take away that exclusive privilege --
>to introduce attributes -- from the language designers and compiler vendors.
>The name space for attributes is too important language resource, it should
>not be given out freely for general use.
>  How about another character instead of apostrophe (or dot) for user-defined
>attributes? For example, there is quite popular # (read "join" for this purpose):
> Object#Operation 
>("controlling object" somehow associates with "base" -:)

Nah - that's ugly :-)


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: The old "Object.Method" syntax debate

[Alexander Kopilovitch]

>>The name space for attributes is too important language resource, it should
>>not be given out freely for general use.
>>  How about another character instead of apostrophe (or dot) for user-defined
>>attributes? For example, there is quite popular # (read "join" for this purpose):
>> Object#Operation 
>>("controlling object" somehow associates with "base" -:)
>
>Nah - that's ugly :-)

Well, perhaps Microsoft wouldn't say so -:)

  Anyway, I just imagined another notation for that purpose, and it seems
worth of discussion: dot-qualified attribute Method, i.e.

  Object'Method.Operation

for example:

  type T is ... ;
  function F(P : T; Q : Integer) return Integer;
  X : T;
  Actual_Q : Integer;
  ...

  X'Method.F(Actual_Q);

For me, this notation looks quite straight. Indeed, one may think that the
attribute Method returns a record -- method table, like in C++ code.
  (If you will argue that the attribute part in this notation is obviously
redundant, I will reply that you English all the time use articles "a" and
"the", which seem no less redundant for Russian native speaker, like me -:) .

  Furthemore, with this approach we may easily provide a denotation for the
corresponding abstraction, that is, unified notation for a component and
a method; all we need for this is another attribute Property, which should be
used the same way:

for both

  type T is ... ;
  function F(P : T) return Integer;

and

  type T is record 
     F : Integer;
     ...
  end record;

we can write:

  X : T;
  R : Integer;
  ...

  R := X'Property.F;


(This approach does not provide assignment to a property; for writable
properties we can rely upon controlled data components.)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: The old "Object.Method" syntax debate

[Gautier Write-only]

Rodrigo Garcia:

> I would be happy if an Ada editor had something similar with package names.
> Once you type the name of a package, you could have a pop-up showing all the
> available operations of the package. Does anybody know of something like
> that? Perhaps GPS?

AdaGIDE has it - the box displays all items exported by the package.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: The old "Object.Method" syntax debate

[Steve]

"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:vcn7svfjbannd6@corp.supernews.com...
> This was brought up in a forum regarding enhancements for Ada0X,
> at the SIG-Ada meeting last December, and the consensus was it
> should be done, so it probably will.
>

If only we could add an alternate syntax for defining the methods (functions
and procedures) associated with an object, such as:

  type obj is tagged
    record
      field : Integer;
      function Fun1( in; value : in integer ) return Integer;
      procedure Proc1( in out; value : in out integer );
    end record;

Yeah, I've mentioned this before, and nobody seems to agree with me, but I
still hate dealing with "freezing rules" to figure out where dispatching
operations end.

Pascal and C/C++ have two forms of "if" statements, one where the "if" is
followed by a single line, the other where the "if" is followed by a block.
Ada has only one form, which always uses an "end if".  I like the form in
Ada a LOT better since it always explicitly gives the bounds of the if
statement.  IMO tagged types (in their current form) do exactly the
opposite, they leave you hanging.

This is one of the very few places I like C++ and Java syntax better than
Ada.

Steve
(The Duck)

> In defense of the charge that the objection is "vacuous," I would point
> out that that notation prevents the need to fully qualify the subprogram
> name (in the absence of use clauses) when invoking the subprogram
> for an object which is in scope.
>
> Having worked in the .NET environment for quite a while, it's really
> nice to be able to type an object name, then the dot, and immediately
> see a little pop-up-window showing all of the available operations,
> and being able to select from the list instead of typing the full
> subprogram name.
>

Re: The old "Object.Method" syntax debate

[Preben Randhol]

Steve wrote:
> "David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
> news:vcn7svfjbannd6@corp.supernews.com...
>> This was brought up in a forum regarding enhancements for Ada0X,
>> at the SIG-Ada meeting last December, and the consensus was it
>> should be done, so it probably will.
>>
> 
> If only we could add an alternate syntax for defining the methods (functions
> and procedures) associated with an object, such as:
> 
>   type obj is tagged
>     record
>       field : Integer;
>       function Fun1( in; value : in integer ) return Integer;
>       procedure Proc1( in out; value : in out integer );
>     end record;
> 
> Yeah, I've mentioned this before, and nobody seems to agree with me, but I
> still hate dealing with "freezing rules" to figure out where dispatching
> operations end.

I think I would agree with you (without knowing the ramifications) for
the new .Method

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[John McCabe]

On Fri, 23 May 2003 14:43:49 GMT, "Steve" <nospam_steved94@attbi.com>
wrote:

>If only we could add an alternate syntax for defining the methods (functions
>and procedures) associated with an object, such as:
>
>  type obj is tagged
>    record
>      field : Integer;
>      function Fun1( in; value : in integer ) return Integer;
>      procedure Proc1( in out; value : in out integer );
>    end record;

An alternative I though of some time back was to 'enhance' the package
construct a 'class package' or perhaps a 'tagged package'. So instead
of:

package X is
   type obj is tagged
      record
         a : integer;
         b : float;
      end record;

   procedure method (object : in out obj);
end X;

You could have something like:

tagged package X is
   a : integer;
   b : float;

   procedure method;
end X;

So 'a' and 'b' would be object attributes and 'method' would be an
object method. This sort of package would essentially define a single
tagged type without all of the record definition and controlling
parameters etc.

Further you could use:

tagged package Y is new X with
   c : some_enumerated_type;
end Y;
etc..



Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: The old "Object.Method" syntax debate

[Robert A Duff]

"Steve" <nospam_steved94@attbi.com> writes:

> Yeah, I've mentioned this before, and nobody seems to agree with me, but I
> still hate dealing with "freezing rules" to figure out where dispatching
> operations end.

You don't need to deal with the freezing rules in order to see which
operations are dispatching.  The freezing rules are an annoyance when
*writing* code, I admit.  But, in a legal piece of Ada code, the
freezing rules have no effect on which operations are dispatching.

- Bob

Re: The old "Object.Method" syntax debate

[Hyman Rosen]

Steve wrote:
> Pascal and C/C++ have two forms of "if" statements, one where the "if" is
> followed by a single line, the other where the "if" is followed by a block.

C and C++ have one form of "if" statement, whose syntax is
     if ( <condition> ) <statement> [ else <statement> ]
(where the () are literal but the [] indicate optional :-)

Re: The old "Object.Method" syntax debate

[Steve]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1JYza.7047$ca5.5487@nwrdny02.gnilink.net...
> Steve wrote:
> > Pascal and C/C++ have two forms of "if" statements, one where the "if"
is
> > followed by a single line, the other where the "if" is followed by a
block.
>
> C and C++ have one form of "if" statement, whose syntax is
>      if ( <condition> ) <statement> [ else <statement> ]
> (where the () are literal but the [] indicate optional :-)
>

While you're technically correct, because C/C++ describe a statement as
either a single line or a block, in my opinion they're really two forms of
an if statement.

if( x != 42 )
{
    DoSomething();
}

Appears (to me) to be a different form from

if( x != 42 )
    DoSomething();

Where Ada only has one form:

if x /= 42 then
  DoSomething;
end if;

Steve
(The Duck)

Re: The old "Object.Method" syntax debate

[Gautier Write-only]

> > C and C++ have one form of "if" statement, whose syntax is
> >      if ( <condition> ) <statement> [ else <statement> ]
> > (where the () are literal but the [] indicate optional :-)

Steve:

> While you're technically correct, because C/C++ describe a statement as
> either a single line or a block, in my opinion they're really two forms of
> an if statement. [...]

Stop! There is only one form: a block is also an instruction.
The joke is that C and Pascal await at most *one* instruction after
"then" and "else". It is a design blunder, of course, since
most of the time you have more than one instruction. As a consequence,
in C and Pascal, you *must* bracket them inside a block
by {..} or begin..end . It looks like a second form since it
is so frequent, but it isn't. Fortunately most language designs
since 1970 (even Fortran 77 and structured Basic's!) forsee
several instructions for loops and conditions.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: The old "Object.Method" syntax debate

[John McCabe]

On 21 May 2003 08:26:35 -0700, mcq95@earthlink.net (Marc A. Criley)
wrote:

>Yeah, I'm bringing this up.  Kill the thread if your eyes just rolled
>up into your head %-)

<..snip..>

>I've pretty much always thought of this as a non-issue not worth all
>the bandwidth that's been expended on it, since it's a matter of
>syntactic sugar.

In most cases it *is* just a syntactic sugar issue, but it's a very
big issue when trying to explain to C++ and Java (and Visual Basic)
users how you would do something equivalent in Ada to what they've
already learned. The fact that Ada "method" calls look absolutely
nothing like what you would expect an object-oriented language's
method calls to look like is, in my view, a big issue in relation to
Ada's acceptance by less broad-minded developers.

As David points out, it *is* very nice to be able to see a pop-up
window of what options are available for an object as soon as you type
the ".".

>But reading that Carlisle's team changed only 127 SLOC in GNAT 3.15 to
>support it, I'm thinking that if it's that cheap to change in a
>compiler (and I know there's all the regression testing and LRM
>updates and so on that would have to accompany such a move), then
>maybe it's worth it to allow the alternate syntax and remove one of
>the admittedly vacuous objections to Ada raised by the language's
>critics.

Agreed.


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: The old "Object.Method" syntax debate

[Preben Randhol]

John McCabe wrote:
> 
> In most cases it *is* just a syntactic sugar issue, but it's a very
> big issue when trying to explain to C++ and Java (and Visual Basic)
> users how you would do something equivalent in Ada to what they've
> already learned. The fact that Ada "method" calls look absolutely
> nothing like what you would expect an object-oriented language's
> method calls to look like is, in my view, a big issue in relation to
> Ada's acceptance by less broad-minded developers.

I can understand this, but what I'm scared of is that we get two
overlapping syntaxes which can be confusing? But I need to read the AI
again because I don't understand how this new syntax works.

> As David points out, it *is* very nice to be able to see a pop-up
> window of what options are available for an object as soon as you type
> the ".".

I find this argument a bit odd. Sure it is nice, but to change the
language so that IDE's are easier to make is a bit strange for me :-)

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[John McCabe]

On Fri, 23 May 2003 08:39:11 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:

>> As David points out, it *is* very nice to be able to see a pop-up
>> window of what options are available for an object as soon as you type
>> the ".".

>I find this argument a bit odd. Sure it is nice, but to change the
>language so that IDE's are easier to make is a bit strange for me :-)

It's not so much to make IDE's are easier to make, it's just that it
is simple for the programmer to see exactly which methods are
appropriate to a particular object.

Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: The old "Object.Method" syntax debate

[Preben Randhol]

John McCabe wrote:
> 
> It's not so much to make IDE's are easier to make, it's just that it
> is simple for the programmer to see exactly which methods are
> appropriate to a particular object.

But this only applies for tagged types?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: The old "Object.Method" syntax debate

[Stephen Leake]

Preben Randhol <randhol+abuse@pvv.org> writes:

> John McCabe wrote:
> > As David points out, it *is* very nice to be able to see a pop-up
> > window of what options are available for an object as soon as you type
> > the ".".
> 
> I find this argument a bit odd. Sure it is nice, but to change the
> language so that IDE's are easier to make is a bit strange for me :-)

Actually, I think making IDE's easier is a good thing. For example, it
is far easier to build a source code browser for Ada than for C++,
because of Ada's simpler syntax.

However, I'm not convinced that object.method makes it easier to
"popup a menu of 'options' for an object". But I've not used an IDE
that has such popups, so maybe I'm not qualified to say.

-- 
-- Stephe

Re: The old "Object.Method" syntax debate

[John McCabe]

On 23 May 2003 13:32:22 -0400, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>However, I'm not convinced that object.method makes it easier to
>"popup a menu of 'options' for an object". But I've not used an IDE
>that has such popups, so maybe I'm not qualified to say.

You ought to try one - they're wonderful things :-) If you've got any
Microsoft Office apps, have a go with the Tools => Macro => Visual
Basic Editor. The VBA editor does this.

Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: The old "Object.Method" syntax debate

[Georg Bauhaus]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:
: However, I'm not convinced that object.method makes it easier to
: "popup a menu of 'options' for an object". But I've not used an IDE
: that has such popups, so maybe I'm not qualified to say.

I think you have, only they are called buffers displayed in a
window inside a frame in Emacs. And these pop up too, even if
you hadn't intended to ask for them to pop up ;-) (Yes, that
can be configured ;-)

(For those who haven't found the more tasty Emacs bits yet:
Identifier completion has been in Emacs for quite some time now,
and it is also possible in a more general form (see abbreviations and
expansions) even if the compiler can't assist because
of syntx errors. GNAT does assist when it can produce an index,
i.e., can compile a unit.)

Georg

Re: The old "Object.Method" syntax debate

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote:
> : However, I'm not convinced that object.method makes it easier to
> : "popup a menu of 'options' for an object". But I've not used an IDE
> : that has such popups, so maybe I'm not qualified to say.
> 
> I think you have, only they are called buffers displayed in a
> window inside a frame in Emacs. And these pop up too, even if
> you hadn't intended to ask for them to pop up ;-) (Yes, that
> can be configured ;-)

Well, I use Emacs, but I don't use this feature. Maybe I'll give it a
try. 

> GNAT does assist when it can produce an index, i.e., can
> compile a unit.

This is usually my objection; when I'm writing code, by definition it
doesn't compile. So fully accurate completion is not possible.

-- 
-- Stephe

Re: The old "Object.Method" syntax debate

[Georg Bauhaus]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:
:> I think you have, only they are called buffers displayed in a
:> window inside a frame in Emacs. And these pop up too, even if
:> you hadn't intended to ask for them to pop up ;-) (Yes, that
:> can be configured ;-)
: 
: Well, I use Emacs, but I don't use this feature. Maybe I'll give it a
: try. 

(Ehm, I had thought of the windows that will will be added to a frame
when it is plausible, like when the window displays a list of compiler
messages, and then the windows that will be added because the author
of the el-code thaught (let's assume he/she did) it was a good
idea to throw some messages at the author.)

: 
:> GNAT does assist when it can produce an index, i.e., can
:> compile a unit.
: 
: This is usually my objection; when I'm writing code, by definition it
: doesn't compile. So fully accurate completion is not possible.

Since Ada supports separate compilation, this is only half true. :-)


Georg

Re: The old "Object.Method" syntax debate

[steve_H]

mcq95@earthlink.net (Marc A. Criley) wrote in message news:<254c16a.0305210726.485125de@posting.google.com>...
 
> We have modified the
> compiler to allow the same object.method syntax [...]  We have also
> performed this modification to the Windows 3.15 version of GNAT.


great!!

This is so cool. 

Ada needs this change badly. It is IMHO, the main thing I find against
Ada not being called an OO language. I know this is a synactic sugar
only issue, but it would make programming in Ada much more easier for
me and many others, I am sure, who are 'used' to the object.method() syntax.

When will this change be in GNAT officially? i.e. the public release
of GNAT?

RE: The old "Object.Method" syntax debate

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Steve [mailto:nospam_steved94@attbi.com]
...
| 
| If only we could add an alternate syntax for defining the 
| methods (functions
| and procedures) associated with an object, such as:
| 
|   type obj is tagged
|     record
|       field : Integer;
|       function Fun1( in; value : in integer ) return Integer;
|       procedure Proc1( in out; value : in out integer );
|     end record;
| 
| Yeah, I've mentioned this before, and nobody seems to agree 
| with me, but I
| still hate dealing with "freezing rules" to figure out where 
| dispatching
| operations end.

I agree with you, Steve, you're no more alone :-) 
Some construction to clearly bound object limits would be good for
readability.

The former suffer from an already raised point here, which is that the
declared profile is not the used profile, and this is not so good for
readability.

Note also that this is not strictly related to the "Object.Method" debate,
as one could consider using your declaration syntax with the current:
Proc1 (Obj, Value, integer);
while forbidding:
Obj.Proc1 (Value, integer);

...
| 
| This is one of the very few places I like C++ and Java syntax 
| better than Ada.
I unfortunatly agree. 
Sticking to Ada 83 syntax as much as possible was a really good goal, but
due to for example to freeze rules, i am not sure that a more different
syntax would have been more difficult to implement within compiler. 

Lionel Draghi.

RE: The old "Object.Method" syntax debate

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: john@nospam.demon.co.uk [mailto:john@nospam.demon.co.uk]
...
| You could have something like:
| 
| tagged package X is
|    a : integer;
|    b : float;
| 
|    procedure method;
| end X;
| 
| So 'a' and 'b' would be object attributes and 'method' would be an
| object method. This sort of package would essentially define a single
| tagged type without all of the record definition and controlling
| parameters etc.
| 
| Further you could use:
| 
| tagged package Y is new X with
|    c : some_enumerated_type;
| end Y;
| etc..
| 
I find this pretty elegant, although using the "package" keyword leads to
the class/module confusion that Ada currently avoid.
And removing "package" brings us not so far from Steve proposal, isn't it?

-- 
Lionel Draghi.

Re: The old "Object.Method" syntax debate

[John McCabe]

On Fri, 23 May 2003 19:59:32 +0200, Lionel.DRAGHI@fr.thalesgroup.com
wrote:

>| -----Message d'origine-----
>| De: john@nospam.demon.co.uk [mailto:john@nospam.demon.co.uk]
>...
>| You could have something like:
>| 
>| tagged package X is
>|    a : integer;
>|    b : float;
>| 
>|    procedure method;
>| end X;
>| 
>| So 'a' and 'b' would be object attributes and 'method' would be an
>| object method. This sort of package would essentially define a single
>| tagged type without all of the record definition and controlling
>| parameters etc.
>| 
>| Further you could use:
>| 
>| tagged package Y is new X with
>|    c : some_enumerated_type;
>| end Y;
>| etc..
>| 
>I find this pretty elegant,

Thank you.

> although using the "package" keyword leads to
> the class/module confusion that Ada currently avoid.

That is a fair point, but it would be interesting to know how much of
the Ada code written in under the 'object-oriented' paradigm actually
uses a single tagged type per package. Over a period of around 3 years
I worked in 2 separate companies where this was pretty much the case.
In fact, in both cases the code structure was automatically generated.

>And removing "package" brings us not so far from Steve proposal, isn't it?

True. It's not very different except for the limitation of one 'class'
per package.

Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

RE: The old "Object.Method" syntax debate

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: john@nospam.demon.co.uk [mailto:john@nospam.demon.co.uk]
...
| 
| > although using the "package" keyword leads to
| > the class/module confusion that Ada currently avoid.
| 
| That is a fair point, but it would be interesting to know how much of
| the Ada code written in under the 'object-oriented' paradigm actually
| uses a single tagged type per package. Over a period of around 3 years
| I worked in 2 separate companies where this was pretty much the case.
| In fact, in both cases the code structure was automatically generated.

I don't think it's a good practice. I find awkward to create create a child
for a class that perfectly fit in the same package.

Simple coding rules are good, but enforcing one class per package (and
calling it always "Object", or "Class") just bring Ada down to other
langages that do not have a strong modularity support and use classes for
this purpose.
Scattering strongly coupled classes on many packages lower readability. 

And there is always a better name than "Object" or "Class". 
Similarly, calling a formal "This" is, i think, a bad practice, there is
always a better name.

Automatically generated code often lead to this, not only because it
simplify the code generator, but because tools (and UML) do not provide
serious support for Ada modularity. 
Most tools don't care, they just target C++ or Java, and so are mainly
"class translator".

-- 
Lionel Draghi

Re: The old "Object.Method" syntax debate

[John McCabe]

On Tue, 3 Jun 2003 19:23:55 +0200, Lionel.DRAGHI@fr.thalesgroup.com
wrote:

>| That is a fair point, but it would be interesting to know how much of
>| the Ada code written in under the 'object-oriented' paradigm actually
>| uses a single tagged type per package. Over a period of around 3 years
>| I worked in 2 separate companies where this was pretty much the case.
>| In fact, in both cases the code structure was automatically generated.

>I don't think it's a good practice. I find awkward to create create a child
>for a class that perfectly fit in the same package.

I don't really understand what you mean there.

>Simple coding rules are good, but enforcing one class per package (and
>calling it always "Object", or "Class") just bring Ada down to other
>langages that do not have a strong modularity support and use classes for
>this purpose.
>Scattering strongly coupled classes on many packages lower readability. 

>And there is always a better name than "Object" or "Class". 
>Similarly, calling a formal "This" is, i think, a bad practice, there is
>always a better name.

>Automatically generated code often lead to this, not only because it
>simplify the code generator, but because tools (and UML) do not provide
>serious support for Ada modularity. 
>Most tools don't care, they just target C++ or Java, and so are mainly
>"class translator".

I agree to some extent with what you say here but, in the first
company I mentioned the code generator was an in-house design written
in Ada that used the output of [insert design tool name here :-)]
generate the code. Although I said there was one tagged type per
package, thinking back on it that wasn't quite true. The effect was
something like that but there was a main tagged type relating to the
actual functionality required, and a couple of tagged types relating
to the overall structure and scheduling mechanisms (queues etc - tasks
weren't used). In the second company I mentioned we used Rational Rose
(UML). In this case we configured the tool to produce reaonable object
and class names based on the classes we created. Having read a number
of articles about using "Object" and "Class", as well as listening to
a number of reasons from other team members why this was a daft idea,
it was decided not to pursue that convention.

Ultimately the "one tagged-type per class" mechanism wasn't
'enforced', but most of the packages came down to that and maintenance
(with a couple of hundred packages) was fairly straightforward.


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'