Re: The best thing/greatest feature summary

Re: The best thing/greatest feature summary

[Wes Groleau]

> I'll post a summary of responses--unless there are so many I can't
> handle them.

Well, both the Eiffel folks and the Ada folks (with a few exceptions)
posted to Usenet instead of e-mail.  The Ada folks were a lot less
evasive than the Eiffel folks, but I'm only going to summarize
what was not posted.

Ada:    concurrency, generics, validation, class mechanism not confused
        with encapsulation mechanism, that a function can return a
        structure of run-time-determined discriminants.

Eiffel: DBC (pre/post-conditions, invariants), multiple inheritance

Both:   clean syntax, static type checking, avoiding errors instead
        of slinging out code faster.

Why:    To be posted next week.

Since I didn't learn much, anyone game for an alternate question?
Let X your favorite and Y the other (of Ada or Eiffel).  What is
the one feature (if any) of Y that you wish was in X ?

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: The best thing/greatest feature summary

[Lothar Scholz]

On Fri, 27 Oct 2000 17:08:14 -0500, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote:
>
>Since I didn't learn much, anyone game for an alternate question?
>Let X your favorite and Y the other (of Ada or Eiffel).  What is
>the one feature (if any) of Y that you wish was in X ?


X := Eiffel
Y := Common Lisp

If wish that the :before :after method to patch a method would
be in Eiffel.

:before and :after let you define a function which is to be called
everytime before another is executed. after does the same thing
after the method is executed.

So you can do some kind of what is called  "multiple separation of
concerns".

For example add "semaphore.aquire" and "semaphore.release"
around a function without touching the source of the function.

Re: The best thing/greatest feature summary

[Peter Horan]

Lothar Scholz wrote:
> 
> On Fri, 27 Oct 2000 17:08:14 -0500, Wes Groleau
> <wwgrol@ftw.rsc.raytheon.com> wrote:
> >
> >Since I didn't learn much, anyone game for an alternate question?
> >Let X your favorite and Y the other (of Ada or Eiffel).  What is
> >the one feature (if any) of Y that you wish was in X ?
> 
> X := Eiffel
> Y := Common Lisp
> 
> If wish that the :before :after method to patch a method would
> be in Eiffel.

What about

class A
feature
    f is
        do
            -- body
        end
end

class B
inherit A
    redefine f
feature
    f is
        do
            -- stuff done before
            Precursor  -- execute the original body
            -- stuff done after
        end
-- 
Peter Horan                     School of Computing and Mathematics
peter@deakin.edu.au             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation 
-- (http://www.cetus-links.org/oo_eiffel.html)

Re: The best thing/greatest feature summary

[Lothar Scholz]

On Fri, 24 Nov 2000 13:15:00 +1100, Peter Horan <peter@deakin.edu.au>
wrote:

>Lothar Scholz wrote:
>> 
>> On Fri, 27 Oct 2000 17:08:14 -0500, Wes Groleau
>> <wwgrol@ftw.rsc.raytheon.com> wrote:
>> >
>> >Since I didn't learn much, anyone game for an alternate question?
>> >Let X your favorite and Y the other (of Ada or Eiffel).  What is
>> >the one feature (if any) of Y that you wish was in X ?
>> 
>> X := Eiffel
>> Y := Common Lisp
>> 
>> If wish that the :before :after method to patch a method would
>> be in Eiffel.
>
>What about
>
>class A
>feature
>    f is
>        do
>            -- body
>        end
>end
>
>class B
>inherit A
>    redefine f
>feature
>    f is
>        do
>            -- stuff done before
>            Precursor  -- execute the original body
>            -- stuff done after
>        end

But you can't add this to a feature dynamically and you must change
the inheritance hierarchie. This is definitely not the purpose of the
before/after methods. Have a look at what is now known as aspect
oriented programming and you will find that eiffel and most other
languages (expect Java and Lisp) really sucks in this area.

Perhaps someone will implement an eiffel aspect weaver as a Ph.D.
thesis. But eiffel is so less used that i don't really expect anything
- it looks that everybody is on the java side.

Re: The best thing/greatest feature summary

[Friedrich Dominicus]

Lothar Scholz <llothar@mailandnews.de> writes:

> 
> But you can't add this to a feature dynamically and you must change
> the inheritance hierarchie. 
do not forger :around methods too ;-)

>This is definitely not the purpose of the
> before/after methods.
No, but the possiblities are breath taking.

>  Have a look at what is now known as aspect
> oriented programming and you will find that eiffel and most other
> languages (expect Java and Lisp) really sucks in this area.
If I got the choice I take Lisp;-)


> 
> Perhaps someone will implement an eiffel aspect weaver as a Ph.D.
> thesis. But eiffel is so less used that i don't really expect anything
> - it looks that everybody is on the java side.
which is obviously not a real choice, isn't it?


Regards
Friedrich

-- 
for e-mail reply remove all after .com 

Re: The best thing/greatest feature summary

[Lothar Scholz]

On Fri, 27 Oct 2000 17:08:14 -0500, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote:

>Since I didn't learn much, anyone game for an alternate question?
>Let X your favorite and Y the other (of Ada or Eiffel).  What is
>the one feature (if any) of Y that you wish was in X ?

Let 

  X := Eiffel
 Y := Java

than the wish is

 Introspection,  e.g.  java.lang.reflexion (i think that was the
package)

Re: The best thing/greatest feature summary

[Tom Hargraves]

I'd like to agree with Lothar Re...

"Lothar Scholz" <llothar@mailandnews.de> wrote in message > Let
>
>   X := Eiffel
>  Y := Java
>
> than the wish is
>
>  Introspection,  e.g.  java.lang.reflexion (i think that was the
> package)
>
>
--------------------------
Let
 X := Ada
 Y := Java

then the wish is

to add java.lang.reflect 'style' routines to the ada language

Here's a simple example where I'd find it useful:

Quite often in user written Ada error handling packages, it is nice to be
able to increase the detail in the error message, and be able to print or
log the name of the routine or class in which it occured. A 'debug' mode so
to speak.

In ada I've seen this done by declaring constant strings which match (at the
time of writing) the text to be displayed or logged. However there is
nothing to link the content of these strings to the items they refer, so
during the life of an application mismatches can occur.

java.lang.reflect has getName, getDeclaringClass, to name but two.

OK, at first sight, it won't be THE Best/Greatest feature of the language,
but small practical improvements do help to popularise a language.

PS. Maybe there is an equivalent 'Name attribute for a routine, or
'Parent_Class_Name attribute, which I've not been able to find. Please
advise!

Re: The best thing/greatest feature summary

[tmoran]

>increase the detail in the error message, and be able to print or
>log the name of the routine or class in which it occured.
  The better Ada compilers give a walkback in the string returned
by Ada.Exceptions.Exception_Information, eg
  CONSTRAINT_ERROR
     Divide By Zero Detected
  On Line Number 7 In TEST.SOME_PROCEDURE
  Called from line number 12 In TEST
and of course you can force an exception just to get such a string.
  If object X is some kind of descendant of a Gun, then
Ada.Tags.Expanded_Name(X'tag) returns a string giving its full
name, eg, Children_Of_A_Gun.Son
  Are those what you mean?

Re: The best thing/greatest feature summary

[Larry Kilgallen]

In article <OTDL5.376306$i5.6185408@news1.frmt1.sfba.home.com>, tmoran@acm.org writes:
>>increase the detail in the error message, and be able to print or
>>log the name of the routine or class in which it occured.
>   The better Ada compilers give a walkback in the string returned
> by Ada.Exceptions.Exception_Information, eg
>   CONSTRAINT_ERROR
>      Divide By Zero Detected
>   On Line Number 7 In TEST.SOME_PROCEDURE
>   Called from line number 12 In TEST
> and of course you can force an exception just to get such a string.

What "the better Ada compilers" do is not really a characteristic of the
language.  VMS gives traceback for all languages, each in accordance with
their limitations (such as not detecting some error in the first place).

Re: The best thing/greatest feature summary

[Tom Hargraves]

<tmoran@acm.org> wrote in message
news:OTDL5.376306$i5.6185408@news1.frmt1.sfba.home.com...
> >increase the detail in the error message, and be able to print or
> >log the name of the routine or class in which it occured.
>   The better Ada compilers give a walkback in the string returned
> by Ada.Exceptions.Exception_Information, eg
>   CONSTRAINT_ERROR
>      Divide By Zero Detected
>   On Line Number 7 In TEST.SOME_PROCEDURE
>   Called from line number 12 In TEST
> and of course you can force an exception just to get such a string.
>   If object X is some kind of descendant of a Gun, then
> Ada.Tags.Expanded_Name(X'tag) returns a string giving its full
> name, eg, Children_Of_A_Gun.Son
>   Are those what you mean?

Thanks for the reply!
I wasn't thinking of the "better Ada compilers" exception case above, more
the case:

"I have a problem in this routine, I'd like to log it (since I'm in 'verbose
mode'), and prefix the problem description with routine name, and optionally
the name of the class I'm having problems in"

The example I tried to express was the sort of problem where there is a
programmable recovery, and in normal operation you don't want to display
messages to the human operator for fear that he/she gets overloaded with
detail. However, during system debugging, this information could be
important to know. e.g. how do I record the fact that I was in routine X
when I couldn't open that setup file and used defaults instead?

The java routines seem to provide this information.

Re: The best thing/greatest feature summary

[James Rogers]

Tom Hargraves wrote:
> 
> Let
>  X := Ada
>  Y := Java
> 
> then the wish is
> 
> to add java.lang.reflect 'style' routines to the ada language
> 
> Here's a simple example where I'd find it useful:
> 
> Quite often in user written Ada error handling packages, it is nice to be
> able to increase the detail in the error message, and be able to print or
> log the name of the routine or class in which it occured. A 'debug' mode so
> to speak.
> 
> In ada I've seen this done by declaring constant strings which match (at the
> time of writing) the text to be displayed or logged. However there is
> nothing to link the content of these strings to the items they refer, so
> during the life of an application mismatches can occur.
> 
> java.lang.reflect has getName, getDeclaringClass, to name but two.
> 

The java.lang.reflect 'style' of routines rely on the fact that Java
creates
a "Class" object for each class defined in a program. This "Class"
object 
contains the name of the class, the name of the Super for the class, and
several other pieces of information. I, for one, do not want this extra
overhead
in realtime programs. Realtime systems are frequently constrained by
memory as well as by timing. The extra overhead of such shadow data
structures
is easily overlooked by developers. In realtime systems the consequences
of
such errors can be disasterous.

If an Ada developer wants such a capability, then all you need is a
simple
generic package with parameters for all the items you want to identify.

Each package can instantiate the generic with appropriate parameter
values.
The generic package would declare the "getName", "getDeclaringClass",
and
other java-like subprograms as needed.

Jim Rogers
Colorado Springs, Colorado

Re: The best thing/greatest feature summary

[Tom Hargraves]

Good point James.
All these ease-of-programming features come at a cost.

But what is the cost here? A few strings can hardly be much of a cost
nowadays. I'm not asking for a 1Mbyte dynamic .GIF icon to popup, just a
routine name...

These 256 byte strings could live quite happily in the corner of the xMbyte
proms and nobody would even know they where there ;-)

(OK, so I'm setting myself up here. There's bound to be a space shuttle
designer out there who knows the weight of a byte of memory and how much it
costs to put it in orbit...)

Regards,
Tom H.

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:39FF1DBD.74184FDC@worldnet.att.net...
>
>
> Tom Hargraves wrote:
> >
> > Let
> >  X := Ada
> >  Y := Java
> >
> > then the wish is
> >
> > to add java.lang.reflect 'style' routines to the ada language
> >
> > Here's a simple example where I'd find it useful:
> >
> > Quite often in user written Ada error handling packages, it is nice to
be
> > able to increase the detail in the error message, and be able to print
or
> > log the name of the routine or class in which it occured. A 'debug' mode
so
> > to speak.
> >
> > In ada I've seen this done by declaring constant strings which match (at
the
> > time of writing) the text to be displayed or logged. However there is
> > nothing to link the content of these strings to the items they refer, so
> > during the life of an application mismatches can occur.
> >
> > java.lang.reflect has getName, getDeclaringClass, to name but two.
> >
>
> The java.lang.reflect 'style' of routines rely on the fact that Java
> creates
> a "Class" object for each class defined in a program. This "Class"
> object
> contains the name of the class, the name of the Super for the class, and
> several other pieces of information. I, for one, do not want this extra
> overhead
> in realtime programs. Realtime systems are frequently constrained by
> memory as well as by timing. The extra overhead of such shadow data
> structures
> is easily overlooked by developers. In realtime systems the consequences
> of
> such errors can be disasterous.
>
> If an Ada developer wants such a capability, then all you need is a
> simple
> generic package with parameters for all the items you want to identify.
>
> Each package can instantiate the generic with appropriate parameter
> values.
> The generic package would declare the "getName", "getDeclaringClass",
> and
> other java-like subprograms as needed.
>
> Jim Rogers
> Colorado Springs, Colorado

Re: The best thing/greatest feature summary

[James Rogers]

What is the cost here? It really depends upon how much of
java.lang.reflect
you really want to emulate.

For instance, most of the classes in java.lang.reflect rely on an
ability
to suppress access checks. They fundamentally violate the access
restrictions
designed into classes and class members.

Do you want to emulate supression of access checks, so that Ada data and 
subprograms defined in the private part of a package specification, or
in
the body of a package, will be have public visibility?

In other words, do you want to be able to destroy encapsulation?

If you only want to emulate the Member interface in java.lang.reflect
you can instantiate the following generic package in the bodies of your 
packages.

-----------------------------------------------------------------------
-- Generic package to define a "common" interface for providing
-- debug information.
-----------------------------------------------------------------------
generic

   Package_Name : String;
   
package Reflect is

   function Get_Package return String;
   function Get_Name return String;
   procedure Set_Name(Id : in String);
   
end Reflect;

-----------------------------------------------------------------------
-- Generic package body to define a "common" interface for providing
-- debug information.
-----------------------------------------------------------------------
with Ada.Strings.Unbounded;

package body Reflect is

   Proc_Name : Ada.Strings.Unbounded.Unbounded_String;

   --------------
   -- Get_Name --
   --------------

   function Get_Name return String is
   begin
      return Ada.Strings.Unbounded.To_String(Proc_Name);
   end Get_Name;

   -----------------
   -- Get_Package --
   -----------------

   function Get_Package return String is
   begin
      return Package_Name;
   end Get_Package;

   --------------
   -- Set_Name --
   --------------

   procedure Set_Name (Id : in String) is
   begin
      Proc_Name := Ada.Strings.Unbounded.To_Unbounded_String(Id);
   end Set_Name;

end Reflect;

------------

I see no reason to make this package part of the language standard
simply
because Java defines an interface with similar capabilities. However,
you may find such a package highly necessary. That is why I have posted
it here. Use it if you wish.

Jim Rogers
Colorado Springs, Colorado


Tom Hargraves wrote:
> 
> Good point James.
> All these ease-of-programming features come at a cost.
> 
> But what is the cost here? A few strings can hardly be much of a cost
> nowadays. I'm not asking for a 1Mbyte dynamic .GIF icon to popup, just a
> routine name...
> 
> These 256 byte strings could live quite happily in the corner of the xMbyte
> proms and nobody would even know they where there ;-)
> 
> (OK, so I'm setting myself up here. There's bound to be a space shuttle
> designer out there who knows the weight of a byte of memory and how much it
> costs to put it in orbit...)
> 
> Regards,
> Tom H.

Re: The best thing/greatest feature summary

[Ken Garlington]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:39FF8DE3.EC0055B5@worldnet.att.net...

: If you only want to emulate the Member interface in java.lang.reflect
: you can instantiate the following generic package in the bodies of your
: packages.
:
: -----------------------------------------------------------------------
: -- Generic package to define a "common" interface for providing
: -- debug information.
: -----------------------------------------------------------------------
: generic
:
:    Package_Name : String;

This, of course, is the critical difference between your solution and the
Java solution. "Package_Name" may, or may not, be the name of the Ada
package -- its correctness is only enforced by the programmer's diligence
(particularly in the face of changes). The Java method does not depend upon
keeping the same information copied in two places, as in

package MyPackage is -- [1]

  package R is new Reflect("MyPackage"); -- [2]

Given that a goal of Ada is to reduce errors due to copying, the argument
that the Ada approach is not as desirable as the Java approach seems like a
valid criticism to me. It gets worse, of course, if you want to implement
more than just the package name: a full implementation of the Java
functionality could presumably include the names of types, objects, record
components, subprograms, parameters /return types, and exception names.

Re: The best thing/greatest feature summary

[Pat Rogers]

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:wiUL5.2554$pq3.156683@news.flash.net...
> "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:39FF8DE3.EC0055B5@worldnet.att.net...
>
> : If you only want to emulate the Member interface in
java.lang.reflect
> : you can instantiate the following generic package in the bodies of
your
> : packages.
> :
>
: --------------------------------------------------------------------
---
> : -- Generic package to define a "common" interface for providing
> : -- debug information.
>
: --------------------------------------------------------------------
---
> : generic
> :
> :    Package_Name : String;
>
> This, of course, is the critical difference between your solution
and the
> Java solution. "Package_Name" may, or may not, be the name of the
Ada
> package -- its correctness is only enforced by the programmer's
diligence
> (particularly in the face of changes). The Java method does not
depend upon
> keeping the same information copied in two places, as in
>
> package MyPackage is -- [1]
>
>   package R is new Reflect("MyPackage"); -- [2]
>
> Given that a goal of Ada is to reduce errors due to copying, the
argument
> that the Ada approach is not as desirable as the Java approach seems
like a
> valid criticism to me. It gets worse, of course, if you want to
implement
> more than just the package name: a full implementation of the Java
> functionality could presumably include the names of types, objects,
record
> components, subprograms, parameters /return types, and exception
names.

There are two facilities within reflection: introspection and
intercession.  The above is an example of introspection, the ability
of a computational process to query a representation of itself.
Intercession allows the process to alter itself.  For example, in the
above discussion, intercession would support the insertion of the
debugging code itself.

Sun's Java only supports run-time introspection, but not intercession.
For a fully reflective implementation of Java see OpenJava
(http://www.hlla.is.tsukuba.ac.jp/~mich/openjava/).  There are others
too.

For my PhD thesis I've implemented compile-time reflection for full
Ada, including both introspection and intercession.  It is similar to
both OpenC++, arguably the most widely used reflective language
(http://www.hlla.is.tsukuba.ac.jp/~chiba/openc++.html), and OpenJava.
At some point I'll make it available.


Pat
---
Patrick Rogers                      Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: The best thing/greatest feature summary

[James Rogers]

Ken Garlington wrote:
> 

> This, of course, is the critical difference between your solution and the
> Java solution. "Package_Name" may, or may not, be the name of the Ada
> package -- its correctness is only enforced by the programmer's diligence
> (particularly in the face of changes). The Java method does not depend upon
> keeping the same information copied in two places, as in
> 
> package MyPackage is -- [1]
> 
>   package R is new Reflect("MyPackage"); -- [2]
> 
> Given that a goal of Ada is to reduce errors due to copying, the argument
> that the Ada approach is not as desirable as the Java approach seems like a
> valid criticism to me. It gets worse, of course, if you want to implement
> more than just the package name: a full implementation of the Java
> functionality could presumably include the names of types, objects, record
> components, subprograms, parameters /return types, and exception names.

Given the current Ada approach to such levels of information I think the
solution would be to add a new set of attributes. Those attributes could
produce string representations of names. 

Exception names become a more costly effort. Ada must be redesigned to
list
raised or unhandled exceptions as part of its signature, as is done in
Java.
Without such a "registration" of exceptions it would be most difficult
and
inefficient to compile a list of exception names for a subprogram.

One of the issues associated with this new set of attributes is stream
representation of objects. Do we pass the name of an object as part of
that object's stream element. Java does this. Java uses this information
to dynamically identify version incompatibilities. Should Ada streams be
burdened with object identifiers also?

If they are, I can promise you that real-time performance in bandwidth
limited
communication channels will suffer badly. Of course, the other
possibility
is for applications to design their own data representation, completely
ignoring streams. This has the effect of making streams completely 
irrelevant.

Jim Rogers
Colorado Springs, Colorado

Re: The best thing/greatest feature summary

[Tom Hargraves]

Meanwhile the ever increasing number of Java programmers are enjoying the
ease of use of the java predefined environment...

I don't want to hurry y'all, but the biggest threat to ada is the fact that
1995-1983=12, and 1995+12=2007

But I digress, the title of this thread is "best", not "worse"

Sorry.

Tom H.

Re: The best thing/greatest feature summary

[Ted Dennison]

In article <3a00924a$1@rsl2.rslnet.net>,
  "Tom Hargraves" <tharg@vtcinet.com> wrote:
> Meanwhile the ever increasing number of Java programmers are enjoying
> the ease of use of the java predefined environment...

If we are to learn lessons from Java, we should take care that its the
right lessons. The main thing I see in Java is that a lot can be
accomplished for a decent new language with a massive media blitz. But
what do you do when its no longer "new"? It has yet to be proven that
this expensively bought popularity can be maintained for any length of
time.

Java's not going to go away. But its rapidly becoming just another
lanaguage. It appears that folks are already casting about for the next
flavor-of-the month. It could be C#, it could be Internet C++...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The best thing/greatest feature summary

[Pat Rogers]

As a proponent of Ada and a friend of Java, let me say that IMHO it is
not the ease of use of the Java predefined environment that makes
people happy.  (I assume you mean both that and the APIs that are
continually being added.)  The language itself is rather underpowered;
hence the environment and the APIs are less than they could otherwise
be.  Rather, it is the *extent* of these APIs that makes the
difference.


"Tom Hargraves" <tharg@vtcinet.com> wrote in message
news:3a00924a$1@rsl2.rslnet.net...
> Meanwhile the ever increasing number of Java programmers are
enjoying the
> ease of use of the java predefined environment...
>
> I don't want to hurry y'all, but the biggest threat to ada is the
fact that
> 1995-1983=12, and 1995+12=2007
>
> But I digress, the title of this thread is "best", not "worse"
>
> Sorry.
>
> Tom H.
>
>
>
>

Re: The best thing/greatest feature summary

[James Rogers]

Pat Rogers wrote:
> 
> As a proponent of Ada and a friend of Java, let me say that IMHO it is
> not the ease of use of the Java predefined environment that makes
> people happy.  (I assume you mean both that and the APIs that are
> continually being added.)  The language itself is rather underpowered;
> hence the environment and the APIs are less than they could otherwise
> be.  Rather, it is the *extent* of these APIs that makes the
> difference.
> 

I have to agree with Pat here. The language defined one other feature
supporting a large and evolving list of APIs. That is the Javadoc tool.
This tool allows decent (not great) documentation of Java APIs in a
consistent HTML format from comments in the Java code.

It turns out that a large list of APIs is useless without the
corresponding
documentation. The feature most often missing from Javadoc documents is
usage examples. On the other hand, the documentation is complete enough
for
any Java-knowledgable programmer to use without significant usage
examples.

Jim Rogers
Colorado Springs, Colorado

Re: The best thing/greatest feature summary

[Pat Rogers]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3A00ABEE.C563EBBA@worldnet.att.net...
>
>
> Pat Rogers wrote:
> >
> > As a proponent of Ada and a friend of Java, let me say that IMHO
it is
> > not the ease of use of the Java predefined environment that makes
> > people happy.  (I assume you mean both that and the APIs that are
> > continually being added.)  The language itself is rather
underpowered;
> > hence the environment and the APIs are less than they could
otherwise
> > be.  Rather, it is the *extent* of these APIs that makes the
> > difference.
> >
>
> I have to agree with Pat here. The language defined one other
feature
> supporting a large and evolving list of APIs. That is the Javadoc
tool.
> This tool allows decent (not great) documentation of Java APIs in a
> consistent HTML format from comments in the Java code.

I've forgotten who said it first here, but I too believe javadoc is a
reaction to a lack of separation between interface and implementation.
I still find myself looking at the code to see what's going on, and
those darned javadoc comments get in the way.  1/2 :-)

Re: The best thing/greatest feature summary

[Pat Rogers]

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3A00ABEE.C563EBBA@worldnet.att.net...
>
> Pat Rogers wrote:
<snip>>
> I have to agree with Pat here.
<snip>
> Jim Rogers

That's because you obviously have high-quality genes!  :-)

Re: The best thing/greatest feature summary

[Wes Groleau]

> > As a proponent of Ada and a friend of Java, let me say that IMHO it is
> > not the ease of use of the Java predefined environment that makes
> > people happy.  (I assume you mean both that and the APIs that are
> > continually being added.)  The language itself is rather underpowered;
> > hence the environment and the APIs are less than they could otherwise
> > be.  Rather, it is the *extent* of these APIs that makes the
> > difference.

That, and the fact that the code looks like C.

> I have to agree with Pat here. The language defined one other feature
> supporting a large and evolving list of APIs. That is the Javadoc tool.
> This tool allows decent (not great) documentation of Java APIs in a
> consistent HTML format from comments in the Java code.

By being being disciplined enough to add comments in a specific format
and running a special tool, one can generate documentation that is
potential equal to, and if you really work at it, even better than a
well-written Ada specification is without comments.  Not a selling point
in my book.

This thread sure forgot about comparing Eiffel and Ada rather quickly.

-- 
Wes Groleau for President of the U.S.A.
http://freepages.rootsweb.com/~wgroleau

Reflection (was: Re: The best thing/greatest feature summary)

[Jeff Carter]

Ken Garlington wrote:
>
> This, of course, is the critical difference between your solution and the
> Java solution. "Package_Name" may, or may not, be the name of the Ada
> package -- its correctness is only enforced by the programmer's diligence
> (particularly in the face of changes). The Java method does not depend upon
> keeping the same information copied in two places, as in
>
> package MyPackage is -- [1]
>
>   package R is new Reflect("MyPackage"); -- [2]
>
> Given that a goal of Ada is to reduce errors due to copying, the argument
> that the Ada approach is not as desirable as the Java approach seems like a
> valid criticism to me.

I've been toying with this:

with Ada.Strings.Fixed;
with Ada.Tags;
with Mixed_Case;

use Ada.Strings.Fixed;
use Ada.Tags;
generic -- Reflection
   -- null;
package Reflection is
   Unit_Name : constant String;
   -- The full name of the unit in which this package is instantiated
   -- (the null string if instantiated at the library level).
   -- Unit_Name is in strict mixed-case form [1st character and every
   -- character after
   -- a dot ('.') or underline ('_') is in upper case, and all other
   -- characters are in lower case].
private -- Reflection
   type T is abstract tagged null record;
   
   Name : constant String := Expanded_Name (T'Tag);
   Dot  : constant String := ".";
   
   Direction : constant Ada.Strings.Direction := Ada.Strings.Backward;
   
   Dot_Location : constant Natural :=
      Index (Name (Name'First .. Index (Name, Dot, Direction) - 1),
             Dot, Direction);
   -- 1st Index finds dot before type name
   -- 2nd Index finds dot before instantiation name
   
   Unit_Name : constant String :=
      Mixed_Case (Name (Name'First .. Dot_Location - 1) );
      -- Trim off type name and instantiation name
end Reflection;

Mixed_Case is a simple function and is left as an exercise for the
reader.

This package indicates that this kind of information is available in
Ada. We just need an easier way to access it.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Ray Blaak]

Jeff Carter <jrcarter@acm.org> writes:
> I've been toying with this:
[...]
> generic -- Reflection
>    -- null;
> package Reflection is
>    Unit_Name : constant String;
>    -- The full name of the unit in which this package is instantiated
[...]
> end Reflection;
[...]
> This package indicates that this kind of information is available in
> Ada. We just need an easier way to access it.

Very cool.

Now if only tagged types could be declared within routines, and then we would
be all set. 

Or does instantiating this package within a routine actually work? (I don't
have an Ada compiler near me at the moment.)

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Reflection (was: Re: The best thing/greatest feature summary)

[tmoran]

>Or does instantiating this package within a routine actually work? (I don't
>have an Ada compiler near me at the moment.)
Using Gnat 3.13p,

with Ada.Tags;
generic package Reflection is
   Unit_Name : constant String;
private -- Reflection
   type T is abstract tagged null record;
   Unit_Name : constant String := Ada.Tags.Expanded_Name (T'Tag);
end Reflection;

package one is
 procedure p;
 procedure q;
end one;

with reflection,
     ada.text_io;
package body one is
 package me is new reflection;
 procedure p is
 begin ada.text_io.put_line(me.unit_name);end p;
 procedure q is
   package myself is new reflection;
 begin
   ada.text_io.put_line(myself.unit_name);
 end q;
end one;

with reflection,
     one,
     ada.text_io;
procedure test is
  package me is new reflection;
begin
  one.p;                              --> ONE.ME.T
  one.q;                              --> ONE.Q.MYSELF.T
  ada.text_io.put_line(me.unit_name); --> TEST.ME.T
end test;

Re: Reflection (was: Re: The best thing/greatest feature summary)

[David C. Hoos, Sr.]

Here is what might be considered an improvement on your package:

with Ada.Tags;
generic
package Reflection is
   Unit_Name : constant String;
private -- Reflection
   type T is abstract tagged null record;
   S : constant String := Ada.Tags.Expanded_Name (T'Tag);
   Unit_Name : constant String := S (1 .. S'Last - 2);
end Reflection;
package One is
 procedure P;
 procedure Q;
end One;
with Reflection,
  Ada.Text_Io;
package body One is
 package Me is new Reflection;
 procedure P is
 begin
   Ada.Text_Io.Put_Line (Me.Unit_Name);
 end P;
 procedure Q is
   package Me is new Reflection;
 begin
   Ada.Text_Io.Put_Line (Me.Unit_Name);
 end Q;
end One;
with Reflection,
     One,
     Ada.Text_Io;
procedure Test_Reflection is
  package Me is new Reflection;
begin
  One.P;                               --> ONE.ME
  One.Q;                               --> ONE.Q.ME
  Ada.Text_Io.Put_Line (Me.Unit_Name); --> TEST_REFLECTION.ME
end Test_Reflection;

<tmoran@acm.org> wrote in message
news:0O9M5.381209$i5.6373651@news1.frmt1.sfba.home.com...
> >Or does instantiating this package within a routine actually work? (I
don't
> >have an Ada compiler near me at the moment.)
> Using Gnat 3.13p,
>
> with Ada.Tags;
> generic package Reflection is
>    Unit_Name : constant String;
> private -- Reflection
>    type T is abstract tagged null record;
>    Unit_Name : constant String := Ada.Tags.Expanded_Name (T'Tag);
> end Reflection;
>
> package one is
>  procedure p;
>  procedure q;
> end one;
>
> with reflection,
>      ada.text_io;
> package body one is
>  package me is new reflection;
>  procedure p is
>  begin ada.text_io.put_line(me.unit_name);end p;
>  procedure q is
>    package myself is new reflection;
>  begin
>    ada.text_io.put_line(myself.unit_name);
>  end q;
> end one;
>
> with reflection,
>      one,
>      ada.text_io;
> procedure test is
>   package me is new reflection;
> begin
>   one.p;                              --> ONE.ME.T
>   one.q;                              --> ONE.Q.MYSELF.T
>   ada.text_io.put_line(me.unit_name); --> TEST.ME.T
> end test;

Re: Reflection (was: Re: The best thing/greatest feature summary)

[tmoran]

>Here is what might be considered an improvement on your package:
   Note this was merely a test of a stripped down version of a package
proposed by Jeff Carter in Message-ID: <3A00E2D0.42440CB0@acm.org>
BTW, it works the same with OA 7.2 as with Gnat 3.13p

Re: Reflection (was: Re: The best thing/greatest feature summary)

[David C. Hoos, Sr.]

Sorry about the earlier post.  This was the improved version I meant to
post:

with Ada.Strings.Fixed;
with Ada.Tags;
generic
package Reflection is
  Name : constant String;
private -- Reflection
  type T is abstract tagged null record;
  S : constant String := Ada.Tags.Expanded_Name (T'Tag);
  Last : constant Positive := Ada.Strings.Fixed.Index
    (S (1 .. S'Last - 2), ".", Ada.Strings.Backward) - 1;
  Name : constant String := S (1 .. Last);
end Reflection;
package One is
procedure P;
procedure Q;
end One;
with Reflection,
  Ada.Text_IO;
package body One is
package Me is new Reflection;
procedure P is
begin
  Ada.Text_Io.Put_Line (Me.Name);
end P;
procedure Q is
  package Me is new Reflection;
begin
  Ada.Text_Io.Put_Line (Me.Name);
end Q;
end One;
with Reflection,
    One,
    Ada.Text_IO;
procedure Test_Reflection is
  package Me is new Reflection;
begin
  One.P;                          --> ONE
  One.Q;                          --> ONE.Q
  Ada.Text_IO.Put_Line (Me.Name); --> TEST_REFLECTION
end Test_Reflection;

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Jeff Carter]

"David C. Hoos, Sr." wrote:
>   Last : constant Positive := Ada.Strings.Fixed.Index
>     (S (1 .. S'Last - 2), ".", Ada.Strings.Backward) - 1;

I prefer not to have magic numbers like 2 in the code. It's worth the
extra call to Index to me.

>   Name : constant String := S (1 .. Last);

>   One.P;                          --> ONE
>   One.Q;                          --> ONE.Q
>   Ada.Text_IO.Put_Line (Me.Name); --> TEST_REFLECTION

And I really prefer to see these in Mixed_Case.

-- 
Jeff Carter
"Illegitimate-faced bugger-folk!"
Monty Python & the Holy Grail

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Tucker Taft]

Ray Blaak wrote:
> 
> Jeff Carter <jrcarter@acm.org> writes:
> > I've been toying with this:
> [...]
> > generic -- Reflection
> >    -- null;
> > package Reflection is
> >    Unit_Name : constant String;
> >    -- The full name of the unit in which this package is instantiated
> [...]
> > end Reflection;
> [...]
> > This package indicates that this kind of information is available in
> > Ada. We just need an easier way to access it.
> 
> Very cool.

I agree, this is a very clever use of Expanded_Name and T'Tag.
GNAT has a few implementation-defined attributes that provide things
like current line number and file name, I believe, and it would
seem a natural extension to provide things like current scope expanded name,
or even generic actual parameter name.  There are lot's of interesting
possibilities here which don't really require run-time reflection, but rather
generic-instantiation-time reflection, which at least in a macro-expanding
model for generics seems quite doable.

> Now if only tagged types could be declared within routines, and then we would
> be all set.

Tagged types can be declared anywhere.  Type extensions are restricted
to being at the same accessibility level as their ancestor types,
but this isn't a type extension.

> Or does instantiating this package within a routine actually work? (I don't
> have an Ada compiler near me at the moment.)

This should work anywhere.

> 
> --
> Cheers,                                        The Rhythm is around me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> blaak@infomatch.com                            The Rhythm has my soul.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Ted Dennison]

In article <m3wvem274n.fsf@ns51.infomatch.bc.ca>,
  Ray Blaak <blaak@infomatch.com> wrote:
> Or does instantiating this package within a routine actually work? (I
> don't have an Ada compiler near me at the moment.)

Not only does it work, but older versions of OpenToken encouraged it!
One nice thing this allows it the ability to use subroutine accesses for
subroutines that aren't declared at the library level (eg: within the
declarations of a "main" subprogram).

The problem is that it *doesn't* work if said generic contains a
controlled type declaration (or any other extension of a library-level
declared tagged type). Personally I think this is a major problem with
controlled types.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> The problem is that it *doesn't* work if said generic contains a
> controlled type declaration (or any other extension of a library-level
> declared tagged type). Personally I think this is a major problem with
> controlled types.

Write to report@gnat.com and request a pseudo-generic version of
Ada.Finalization (which can be instantiated at the level you need).  I
think I've read that adding something along these lines is not too
complicated, but it hasn't been done because no one seems to be
needing it.

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Jeff Carter]

Ray Blaak wrote:
> Now if only tagged types could be declared within routines, and then we would
> be all set.

You can declare tagged types within nested scopes. Perhaps you're
thinking of extending library-level tagged types.

> 
> Or does instantiating this package within a routine actually work? (I don't
> have an Ada compiler near me at the moment.)

It works fine. My test program instantiates it in the program, at the
library level, in a procedure and a function in a library-level package,
and in named and unnamed blocks.

-- 
Jeff Carter
"Illegitimate-faced bugger-folk!"
Monty Python & the Holy Grail

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Randy Brukardt]

Jeff Carter wrote in message <3A00E2D0.42440CB0@acm.org>...

>This package indicates that this kind of information is available in
>Ada. We just need an easier way to access it.

You ought to keep in mind that most implementations would not generate
this information or put it into your program, except that your
instantiation requires it.

OTOH, if these were attributes, it probably would always have to put
into the program. That could increase the size of programs unacceptibly.

                Randy.

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Ken Garlington]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:LIrM5.5484$qR3.1689680@homer.alpha.net...
: Jeff Carter wrote in message <3A00E2D0.42440CB0@acm.org>...
:
: >This package indicates that this kind of information is available in
: >Ada. We just need an easier way to access it.
:
: You ought to keep in mind that most implementations would not generate
: this information or put it into your program, except that your
: instantiation requires it.
:
: OTOH, if these were attributes, it probably would always have to put
: into the program. That could increase the size of programs unacceptibly.

I know of at least one compiler that provides an option to omit internal
constants stored to support 'Image (of course, you can't use 'Image if you
use this option). I imagine other compilers could also optimize this storage
as needed (presumably, this is no different than optimizing the storage
needed for Ada.Tags.Expanded_Name).

Re: Reflection (was: Re: The best thing/greatest feature summary)

[Jeff Carter]

Randy Brukardt wrote:
> OTOH, if these were attributes, it probably would always have to put
> into the program. That could increase the size of programs unacceptibly.

Attributes of what? I haven't been successful in thinking of anything
that it makes sense to have an attribute for in order to obtain this
kind of information. A standard package with functions seems more
appropriate, and might address these overhead concerns.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: The best thing/greatest feature summary

[jacob navia]

When you use lcc-win32 (a C compiler) with the -g4 option, any trap/error,
etc will be displayed in the screen with:
    Trap in function foo foo.c line 243
    called from baz baz.c line 45
    called from yyy yyy.c line 77
    etc

There is a function _stacktrace() that allows you to show that when you want
in your code

> Here's a simple example where I'd find it useful:
>
> Quite often in user written Ada error handling packages, it is nice to be
> able to increase the detail in the error message, and be able to print or
> log the name of the routine or class in which it occured. A 'debug' mode
so
> to speak.
>
> In ada I've seen this done by declaring constant strings which match (at
the
> time of writing) the text to be displayed or logged. However there is
> nothing to link the content of these strings to the items they refer, so
> during the life of an application mismatches can occur.
>
> java.lang.reflect has getName, getDeclaringClass, to name but two.
>
> OK, at first sight, it won't be THE Best/Greatest feature of the language,
> but small practical improvements do help to popularise a language.
>
> PS. Maybe there is an equivalent 'Name attribute for a routine, or
> 'Parent_Class_Name attribute, which I've not been able to find. Please
> advise!
>
>
>

Re: The best thing/greatest feature summary

[Wes Groleau]

> > I'll post a summary of responses--unless there are so many I can't
> > handle them.
> 
> Why:    To be posted next week.

Never mind.  I'd just be rephrasing what's already posted.

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: The best thing/greatest feature summary

[Roger Browne]

Wes Groleau wrote:

> Let X your favorite and Y the other (of Ada or Eiffel).  What is
> the one feature (if any) of Y that you wish was in X ?

The one Ada feature that I wish was in Eiffel is safer numerics. For a
language that cares about correctness, Eiffel is rather sloppy about
things like arithmetic overflow.

Regards,
Roger
-- 
Roger Browne - roger@eiffel.tm - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428

Re: The best thing/greatest feature summary

[Greg]

In article <20001030201951.6DCE4875.NFL@localhost.local>,
  roger@eiffel.tm wrote:
> Wes Groleau wrote:
>
> > Let X your favorite and Y the other (of Ada or Eiffel).  What is
> > the one feature (if any) of Y that you wish was in X ?
>
> The one Ada feature that I wish was in Eiffel is safer numerics. For a
> language that cares about correctness, Eiffel is rather sloppy about
> things like arithmetic overflow.
>
> Regards,
> Roger
> --
> Roger Browne - roger@eiffel.tm - Everything Eiffel
> 19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
>

Part of the price one pays for targeting ANSI C as your assembly
language?

Greg

--
http://homestead.deja.com/user.gmc333/index.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The best thing/greatest feature summary

[Roger Browne]

> > The one Ada feature that I wish was in Eiffel is safer numerics. For a
> > language that cares about correctness, Eiffel is rather sloppy about
> > things like arithmetic overflow.
> 
> Part of the price one pays for targeting ANSI C as your assembly
> language?

No doubt that's the origin of the sloppiness, but there's no requirement
for an Eiffel compiler to target ANSI C (even though most do). Visual
Eiffel compiles and links directly to x86 binaries, without involving C
along the way.

Regards,
Roger
-- 
Roger Browne - roger@eiffel.tm - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428