Ada requires too much typing!

Ada requires too much typing!

[Peter C. Chapin]

This is just an observation on the difference between two communities.

I've been recently using Scala for a project (I'd rather use Ada, but it's
hard for me to justify the cost of converting... alas). Scala is a
functional/OO hybrid language that targets the JVM. It prides itself on,
among other things, its concise syntax. Not surprisingly the Scala community,
as evidenced by the posts on a Scala newsgroup, regard conciseness as an
important feature for a programming language. I agree that conciseness can in
some cases improve readability. However, I also believe that it can obscure a
lot of important detail and make it hard to understand the execution cost of
the code. Perhaps because of my experience with Ada, or perhaps because of my
basic personality, I'm not necessarily a fan of extreme conciseness.

However, the argument that I see some people putting forth on the Scala group
is that conciseness is good because it saves typing. I really can't
understand that. How hard is it to type?

One of the people on that group posted this comment related to the fact that
Java requires public/private access specifiers on methods whereas Scala uses
public by default. Thus in the "common" case of a public method you don't
have to type the word 'public'...

<quote>
The whole "I will make you do extra work coding just so you can demonstrate
to me that you're not being lazy" attitude of Java is perhaps useful in some
situations, but we already have Java for that.  I don't think adopting that
attitude of making you do busywork would be an asset for Scala.

  --Rex
</quote>

Hmmm... "busywork"... interesting. I can only imagine what this person, or
others in that community, would have to say about Ada... or SPARK!

Peter

Re: Ada requires too much typing!

[Ludovic Brenta]

Peter C. Chapin wrote on comp.lang.ada:
> <quote>
> The whole "I will make you do extra work coding just so you can demonstrate
> to me that you're not being lazy" attitude of Java is perhaps useful in some
> situations, but we already have Java for that.  I don't think adopting that
> attitude of making you do busywork would be an asset for Scala.
>
>   --Rex
> </quote>
>
> Hmmm... "busywork"... interesting. I can only imagine what this person, or
> others in that community, would have to say about Ada... or SPARK!

Interpreting an rephrasing Rex's words: "Scala is for lazy
programmers; non-lazy ("serious"?) programmers should use Java." If he
really thinks Java is for the non-lazy ("serious"?) programmers, then
he needs a reality check. If Scala is for lazy programmers, then I'd
rather not have anything to do with it or with said programmers :)

Also interesting is his word "coding". In his mind, Java and Scala are
both for "coding", not for "writing" or "designing" or "explaining" a
program. In this light I can understand him; since both languages can
only convey "code", verbosity is of little value indeed.

Ada, by contrast, is not for "coders", it is for software engineers.
Ada program text (as opposed to "source code") carries a lot of
information about the design and intent of the program; about the whys
and wherefores and not just about the hows. *This* is the value of
verbosity.

Like I said earlier: sloppy programmers avoid Ada, therefore Ada helps
avoid sloppy programmers.

--
Ludovic Brenta.

Re: Ada requires too much typing!

[Jeffrey R. Carter]

Peter C. Chapin wrote:
> 
> However, the argument that I see some people putting forth on the Scala group
> is that conciseness is good because it saves typing. I really can't
> understand that. How hard is it to type?

The important point is that in the real world, code is written once, but read 
many times. I'm sure this is just as true with Scala as it is with every other 
language. So saving typing at the cost of making it harder to read is a false 
economy. Any project where money is involved should take that into consideration.

As Preben Randhol put it, "Saving keystrokes is the job of the text editor, not 
the programming language."

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Ada requires too much typing!

[Adam Beneschan]

On May 26, 5:57 am, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> This is just an observation on the difference between two communities.
>
> I've been recently using Scala for a project (I'd rather use Ada, but it's
> hard for me to justify the cost of converting... alas). Scala is a
> functional/OO hybrid language that targets the JVM. It prides itself on,
> among other things, its concise syntax. Not surprisingly the Scala community,
> as evidenced by the posts on a Scala newsgroup, regard conciseness as an
> important feature for a programming language. I agree that conciseness can in
> some cases improve readability. However, I also believe that it can obscure a
> lot of important detail and make it hard to understand the execution cost of
> the code. Perhaps because of my experience with Ada, or perhaps because of my
> basic personality, I'm not necessarily a fan of extreme conciseness.
>
> However, the argument that I see some people putting forth on the Scala group
> is that conciseness is good because it saves typing. I really can't
> understand that. How hard is it to type?

not hard 4 u obvsly but we dealng w generation hu thnks "lengthy
essay" means sumth 2 long 2 fit in2 Twitter msg

                          -- a

Re: Ada requires too much typing!

[Peter Hermann]

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> Like I said earlier: sloppy programmers avoid Ada, therefore Ada helps
> avoid sloppy programmers.
> 
> --
> Ludovic Brenta.

(-:
www.ihr.uni-stuttgart.de/fileadmin/user_upload/autoren/ph/ada/resources_on_ada.html#quote
:-)

Ludovic: should I remove the "to"?

Re: Ada requires too much typing!

[Ludovic Brenta]

Peter Hermann wrote on comp.lang.ada:
> Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> > Like I said earlier: sloppy programmers avoid Ada, therefore Ada helps
> > avoid sloppy programmers.
>
> > --
> > Ludovic Brenta.
>
> (-:www.ihr.uni-stuttgart.de/fileadmin/user_upload/autoren/ph/ada/resourc...
> :-)
>
> Ludovic: should I remove the "to"?

Yes, you should. And thanks for making believe I'm famous :)

--
Ludovic Brenta.

Re: Ada requires too much typing!

[Georg Bauhaus]

On 26.05.10 14:57, Peter C. Chapin wrote:

> One of the people on that group posted this comment related to the fact that
> Java requires public/private access specifiers on methods whereas Scala uses
> public by default. Thus in the "common" case of a public method you don't
> have to type the word 'public'...

In this particular case of writing "public" or not, there is an
interesting point. If you allow defaults, then omitting access
specifiers should mean "public", not anything else. The reason
is that this default forces programmers to get their publicly
announced subprograms right, semantically, to be called by just
anyone.

Ideally, of course. I don't know whether lazy use of a keyboard
enables programmers to use the few seconds to get the interface right.

Ada in a sense makes specifying access (syntactically) simpler:
everything before "private" is public, without mention.
That leaves a question: is specifying access using visibility
rules and child packages artistry? ;-)

Anyway, if understanding text requires more than linear
reading, there are arguments in favor of conciseness.
UML or any other "bird's eye view" tool show the usefulness
of seeing relations between pieces of source text in one place.

Re: Ada requires too much typing!

[Pascal Obry]

Ludovic,

> Like I said earlier: sloppy programmers avoid Ada, therefore Ada helps
> avoid sloppy programmers.

Agreed 100%, that's probably the easiest way to attract only sane
programmers on your project :) I've done that, it works!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 26 May 2010 15:29:31 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> Also interesting is his word "coding". In his mind, Java and Scala are
> both for "coding", not for "writing" or "designing" or "explaining" a
> program.
We meet on this feeling : we should be writing, not coding (“coding”, this  
word hearts my eyes/hears)

Was pleasant to read this :)

-- 
There is even better than a pragma Assert: a SPARK --# check.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 26 May 2010 19:20:00 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> Anyway, if understanding text requires more than linear
> reading, there are arguments in favor of conciseness.
> UML or any other "bird's eye view" tool show the usefulness
> of seeing relations between pieces of source text in one place.
Did you ever heard about Literate Programming ? What do you think about it  
in this area ? (possibly with editor support for that)

-- 
There is even better than a pragma Assert: a SPARK --# check.

Re: Ada requires too much typing!

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Did you ever heard about Literate Programming ? What do you think
> about it in this area ? (possibly with editor support for that)

Your earlier remarks about LP reminded me of nuweb
(http://sourceforge.net/projects/nuweb/) and my desire to write more
extensive unit tests for the Booch Components
(http://sourceforge.net/projects/booch95/). 

nuweb-related work so far at http://public.me.com/simon.j.wright,
subdirectory lp/ - bc_tests.w is the web source, .pdf the readable
version of it, the .gpr and .ad[bs] files are the generated code.

One thing I find is that LP is fine for the overall description BUT you
have to get down to the detail at some point and there comes a time when
it really doesn't justify a lot of explanation. As an example, section
4.1 in bc_tests.pdf isn't too bad but sections 4.2, 4.3 and 4.4 are just
boring.

Of course writing unit tests for several different versions of the same
concept is going to be boring anyway!

Re: Ada requires too much typing!

[Georg Bauhaus]

On 5/26/10 9:33 PM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 26 May 2010 19:20:00 +0200, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de> a écrit:
>> Anyway, if understanding text requires more than linear
>> reading, there are arguments in favor of conciseness.
>> UML or any other "bird's eye view" tool show the usefulness
>> of seeing relations between pieces of source text in one place.
> Did you ever heard about Literate Programming ? What do you think about
> it in this area ? (possibly with editor support for that)
>

There even was/is a WEB adaptation for Ada 83
with all the features of the original WEB.
Like the other WEB systems, it can help with PERFORM-like
subdivisions, but not act as a replacement for "powerful"
operators (APL style), or with seeing call chains, say. (The tools
to show the latter are all outside the language, I think.)
    Being able to give detailed procedures as to how an operation
is to be performed (Ada) comes at a price (more things
to specify). Program planners who would rather leave the
programming to the engineers might then say "not my job!"
and go on with writing algorithms very concisely,
not using Ada ;-)  Understanding an algorithm might
be easier without the details...


Hypothesis: Compiler makers don't like the literate programming
tools out there.  Reason: Literate Programming makes your
programming language appear to be less than perfect for
structuring. :-)


IIRC, Robert Dewar once explained how Jean Ichbiah used
Word for writing about Ada and then called macros to
copy Ada text from the Word document to some external file.

Re: Ada requires too much typing!

[Fritz Wuehler]

Like anything you need to strike a balance. As many people know, Ada was
designed to be read. It is one of the best in that regard, probably only
COBOL comes close and it's not nearly as powerful.

Extremes in the the direction of terseness are APL and Perl. They can be
impossible to read. Sometimes even reading code you wrote last week is
hard. I'm sure there are others but those two come to mind at the moment.

People mostly lack discipline and gravitate towards lazy practices. C++
coders often call Ada (if they even hear about it) verbose. It's silly, but
I really don't care. It's their problem, not ours. Sloppy code can be
written in any language, and unfortunately it's proven in practice. Still,
sloppy code in some languages is easier to understand than others, but Ada
makes it harder than average to write sloppy code that's also wrong.

There's also the matter of aesthetics. Most programming languages
(especially C and Java and their offspring) are just ugly. I prefer ALGOL
and its derivatives, in my view they're prettier, cleaner, and better. To
each his own, but don't expect me to read your crap if you code it in C,
C++, or Java!

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Thu, 27 May 2010 04:07:19 +0200, Fritz Wuehler  
<fritz@spamexpire-201005.rodent.frell.theremailer.net> a écrit:
> Extremes in the the direction of terseness are APL and Perl. They can be
> impossible to read. Sometimes even reading code you wrote last week is
> hard. I'm sure there are others but those two come to mind at the moment.
Sed scripts ?

-- 
There is even better than a pragma Assert: a SPARK --# check.

Re: Ada requires too much typing!

[Warren]

Jeffrey R. Carter expounded in news:htjce2$31g$1@tornado.tornevall.net:

> Peter C. Chapin wrote:
>> However, the argument that I see some people putting forth on the
>> Scala group is that conciseness is good because it saves typing. I
>> really can't understand that. How hard is it to type?
> 
> The important point is that in the real world, code is written once,
> but read many times. I'm sure this is just as true with Scala as it is
> with every other language. 

Not so (snickers) - Perl is read once, rewritten many times.

Even the perl code's author can't remember how it worked,
3 months later ;-)

Warren

Re: Ada requires too much typing!

[Warren]

Fritz Wuehler expounded in
news:0620a415e6bbc1a5629e906e27bec5cb@msgid.frell.theremailer.net: 

> Like anything you need to strike a balance. As many people know, Ada
> was designed to be read. ..
> 
> People mostly lack discipline and gravitate towards lazy practices.
> C++ coders often call Ada (if they even hear about it) verbose. It's
> silly, but I really don't care. It's their problem, not ours. Sloppy
> code can be written in any language, and unfortunately it's proven in
> practice.

I don't mind C++ too much, until you start looking at 
"templates". To me, the "templates" idea seemed like
a bag on the side to solve the generic problem. C/C++ 
already had substantial syntax up to that point. 
Then templates was shoe-horned into the compiler and
the linker was mangled to make it all work. Even 
more, I find myself with a gag reflex whenever 
I look at STL use.

Ada's generics are also somewhat tricky (the subject of
generics is complex), but it seems an order of magnitude 
cleaner and simpler to understand. Certainly using 
instantiated code is far simpler. Also for the end reader,
it is far easier to read, with generics.

> Still, sloppy code in some languages is easier to understand
> than others, but Ada makes it harder than average to write sloppy code
> that's also wrong. 

One feature I love is the enumerated type in Ada. As long as
you code each when clause in a case statement and avoid "when
others =>", it makes extending an application a breeze. You can
then add one new element to that enumerated type and then the 
compiler will point out every point in the project that needs 
your attention.

> There's also the matter of aesthetics. Most programming languages
> (especially C and Java and their offspring) are just ugly.

I've been using C for almost my entire career. So when it is
properly formatted, it doesn't look ugly to me. But I have 
seen a lot of ugly C/C++ code. The worst example was an XMODEM
(I'm dating myself) program using macros to make the C code
look like PASCAL!! It was macro'd to death. I finally ran it
through cpp and refactored it, in order to make it useful. 
That original code probably still exists somewhere out on 
the net (maybe SIMTEL archives?)  Scary that.

I do find that reading someone else's Ada code is far breezier 
than C/C++/java code. IMO, C# has made it extra ugly with 
the new syntax embedded in it. I like Ada's sparse use
of symbols (no {} or [] for example).

> I prefer
> ALGOL and its derivatives, in my view they're prettier, cleaner, and
> better. To each his own, but don't expect me to read your crap if you
> code it in C, C++, or Java!

Perl is the worst. You'd have to pay me well to look at someone's
perl code. ;-)

Warren

Re: Ada requires too much typing!

[Adam Beneschan]

On May 27, 10:10 am, Warren <ve3...@gmail.com> wrote:
> Not so (snickers) - Perl is read once, rewritten many times.
>
> Even the perl code's author can't remember how it worked,
> 3 months later ;-)

That's why Perl, and many other computer languages, provide features
called "comments".  But I suspect our friend Rex would think that the
purpose of comments is just busywork to prove to some evil IT
supervisor that his employees aren't lazy.  :)

                                   -- Adam

Re: Ada requires too much typing!

[Luis Espinal]

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

In article , Peter C. Chapin says...
>
>However, the argument that I see some people putting forth on the Scala group
>is that conciseness is good because it saves typing. I really can't
>understand that. How hard is it to type?

You have to understand the Scala argument within the context of verbosity in
Java (I'm a Java developer btw.) For many things in Java, Swing programming for
example, we require the creation of (usually anonymous) classes implementing
listener interfaces or swingthread base classes. After a few non-trivial
additions, the syntax becomes horrendously heavy and unwieldy. There is no
notion of nested methods, much less passing functions as parameters (as in
Scala.) That is the type of syntax conciseness and facilities (which are missing
in Java) that makes this type of task easier to read, reuse and maintain.

With the addition of generics in Java, the situation has gotten worse. We need
to use generics to make typing stronger (and to avoid run-time casting errors).
And yet, the syntax is terrible. Try to create, say, create a function that
takes as argument, say, a Map parametrized with subclasses of a given
parametrized class as keys, and container parametrized to a different type as
values. It's an abomination. In Scala, it is much simpler and efficient, ergo
more economical.

>
>One of the people on that group posted this comment related to the fact that
>Java requires public/private access specifiers on methods whereas Scala uses
>public by default. Thus in the "common" case of a public method you don't
>have to type the word 'public'...
>

I don't think that is much of an issue. Mutability is. This is a big issue for
Java as it has turned out. The commonly accepted best practice now is to mark
variables and parameters as final unless you know before hand that you want to
change them. This is a big improvement, but it is not the default behavior. It
is in Scala.


>
>The whole "I will make you do extra work coding just so you can demonstrate
>to me that you're not being lazy" attitude of Java is perhaps useful in some
>situations, but we already have Java for that.  I don't think adopting that
>attitude of making you do busywork would be an asset for Scala.
>
>  --Rex


This doesn't make any sense. It has nothing to do with being lazy. Verbosity has
its place when you want to make some sort of intention clear. That is not the
case in Java. The verbosity that we get now in Java with the addition of
generics (which you don't get in Scala), the inability to create lambdas  (which
we can in Scala, Groovy and JavaScript), lack of "elvis" operators, and the
boiler plate required for checked exceptions (which no other language has),
that's what makes things very difficult to create.

And you can create something that can compile and still not work as intended
because the verbosity gets in the way (specially when you need to throw "super"
or "extend" into the parameter declaration.) The code that we create now, post
Java 1.5 is a lot different from what was being built when the language was
first envision. After the addition of generics, the verbosity that we use to
praise now gets in ways we never imagined.

We have also come to learn that interfaces, the prohibition of multiple
inheritance, lack of operator overloading and checked exceptions were not a good
idea at all. Scala represents a re-thinking on programming on the JVM that has
come out of necessity, and it will most definitely engender Java's replacement
within the next 10-15 years.

Verbosity only has its place if it makes your intentions readable and if it has
precise, easy-to-understand semantics. Verbosity with obscure semantics, that
doesn't give you anything, that can compile and give you hard-to-find errors, we
don't need that.

You got it completely wrong. That's not laziness. It is cleaning out the garbage
and bring a new (and hopefully better) way to program the type of systems we
want to run on the JVM.

I would strongly suggest you listen to the JavaPosse and Software Engineering
Radio podcasts that relate to Scala and other alternative JVM languages. They do
a good job at explaining the reasoning behind the shrinking of verbosity. If you
don't believe me, just try the example I mentioned (the parametrized Map with
subclasses of a parametrized parent as keys, and collections parametrized to a
different type as values.)  It is not an uncommon construct or a
proof-of-concept toy. It is very easy to have combination of 3, 4 parametrized
types, or more.

Try to get that to work on Java, and then on Scala. You'll soon appreciate their
point of view has nothing to do with being lazy.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Fri, 28 May 2010 07:25:15 +0200, Luis Espinal <Luis_member@newsguy.com>  
a écrit:
> the
> boiler plate required for checked exceptions (which no other language
> has),
> [...]
> lack of operator overloading and checked exceptions were
What is this about “checked” exceptions ? (a non-Java guru talking).

> lack of "elvis" operators, and
Elvis ? Does it mean the same as with the good-old Borland Turbo-Pascal ?

--
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Georg Bauhaus]

On 28.05.10 07:25, Luis Espinal wrote:

> With the addition of generics in Java, the situation has gotten worse. We need
> to use generics to make typing stronger (and to avoid run-time casting errors).
> And yet, the syntax is terrible. Try to create, say, create a function that
> takes as argument, say, a Map parametrized with subclasses of a given
> parametrized class as keys, and container parametrized to a different type as
> values. It's an abomination. In Scala, it is much simpler and efficient, ergo
> more economical.

Just for a better understanding, does the following example
exhibit some of the generic syntax "abomination"?


import java.util.HashMap;
import java.util.TreeSet;

public class News<T extends Comparable>
{

    class Things extends TreeSet<T> {}
    class Counts extends HashMap<Integer, Things> {}

    int howmany(final Counts in_here) {
        int sum = 0;
        for (Things t : in_here.values()) {
            sum += t.size();
        }
        return sum;
    }
}


Has Andrew Appel's Critique of ML influenced the syntax?
I would hope so; Appel explains in some detail the mistakes that were
carved in stone when defining ML; a quick scan of FunDef and Expr
in the Scala syntax makes me assume---perhaps wrongly---that
once again I need not mark the end of things!!!   (Which typically
entails horrible error messages such as when the next definition
is parsed as the second argument to the foregoing definition,
in which the programmer had forget the second argument *and*
omitted the optional end marker.)

Re: Ada requires too much typing!

[Alex R. Mosteo]

Luis Espinal wrote:

>(...)
> We have also come to learn that interfaces, the prohibition of multiple
> inheritance, (...) were not a good idea at all.

Thanks for the elaborate reply. Not expert in Scala/Java so I can't comment 
about most of it.

However, seeing that Ada has just copied Java interfaces, I'd like to known 
a bit more in detail why you say what I quoted, if you have the time. I have 
used interfaces a bit and indeed have some grudges with them, but I'd like 
to know if the situation is worse than I think -- or perhaps I'm not using 
them 100% properly.

Thanks in advance,

Alex.

Re: Ada requires too much typing!

[Warren]

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

Adam Beneschan expounded in news:c86a76ae-5b25-4c13-a026-5439a57803f6
@k25g2000prh.googlegroups.com:

> On May 27, 10:10�am, Warren <ve3...@gmail.com> wrote:
>> Not so (snickers) - Perl is read once, rewritten many times.
>>
>> Even the perl code's author can't remember how it worked,
>> 3 months later ;-)
> 
> That's why Perl, and many other computer languages, provide features
> called "comments".  But I suspect our friend Rex would think that the
> purpose of comments is just busywork to prove to some evil IT
> supervisor that his employees aren't lazy.  :)
> 
>                                    -- Adam

I once had the, ahem, pleasure of fixing a summer student's
program after he left to resume his education. He obviously
did not understand what comments where for. They were mostly
like this one:

-- The next statement adds 1 to the current value of I

I = I + 1

Yikesy! The comments not only didn't help but
they got in the way of reading the code (not
to mention that variables were also poorly named).

Warren

Re: Ada requires too much typing!

[John B. Matthews]

In article <op.vdek5asaule2fv@garhos>,
 Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> wrote:

> Le Fri, 28 May 2010 07:25:15 +0200, Luis Espinal <Luis_member@newsguy.com>  
> a écrit:
[...]
> > lack of operator overloading

I prefer Ada's approach in this, but Java is acceptable. Here's a 
simple example implemented in both Ada and Java for comparison:

<http://home.roadrunner.com/~jbmatthews/misc/groots.html>
<http://sites.google.com/site/drjohnbmatthews/polyroots>

> and checked exceptions were What is this about “checked” exceptions ? 
> (a non-Java guru talking).

In Java, the presence of a suitable handler for checked exceptions is 
enforced at compile-time:

<http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2>

The feature may be regarded as controversial:

<http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Fri, 28 May 2010 11:52:09 -0400, John B. Matthews wrote:

> In Java, the presence of a suitable handler for checked exceptions is 
> enforced at compile-time:
> 
> <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2>
> 
> The feature may be regarded as controversial:
> 
> <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html>

BTW, this is the same issue as with Eiffel's "contracts" and Ada's
assertions. The problem is misuse of exceptions:

1. IF the exception is a part of the contracts <=> the client is supposed
to handle it, THEN it must be checked.

2. IF no client can handle it, THEN it shall not be, the program must
rather abort itself or break into the debugger. 

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

Re: Ada requires too much typing!

[Georg Bauhaus]

On 28.05.10 19:31, Dmitry A. Kazakov wrote:
> On Fri, 28 May 2010 11:52:09 -0400, John B. Matthews wrote:
> 
>> In Java, the presence of a suitable handler for checked exceptions is 
>> enforced at compile-time:
>>
>> <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2>
>>
>> The feature may be regarded as controversial:
>>
>> <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html>
> 
> BTW, this is the same issue as with Eiffel's "contracts" and Ada's
> assertions. The problem is misuse of exceptions:
> 
> 1. IF the exception is a part of the contracts <=> the client is supposed
> to handle it, THEN it must be checked.
> 
> 2. IF no client can handle it, THEN it shall not be, the program must
> rather abort itself or break into the debugger. 

2. is what Eiffel programs do, but the compiler does not check
the presence of exception handlers for postconditions that
may fail (and thus raise an exception).  If it did, will it not
mean exception handlers pretty much everywhere?

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Fri, 28 May 2010 21:05:00 +0200, Georg Bauhaus wrote:

> On 28.05.10 19:31, Dmitry A. Kazakov wrote:
>> On Fri, 28 May 2010 11:52:09 -0400, John B. Matthews wrote:
>> 
>>> In Java, the presence of a suitable handler for checked exceptions is 
>>> enforced at compile-time:
>>>
>>> <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2>
>>>
>>> The feature may be regarded as controversial:
>>>
>>> <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html>
>> 
>> BTW, this is the same issue as with Eiffel's "contracts" and Ada's
>> assertions. The problem is misuse of exceptions:
>> 
>> 1. IF the exception is a part of the contracts <=> the client is supposed
>> to handle it, THEN it must be checked.
>> 
>> 2. IF no client can handle it, THEN it shall not be, the program must
>> rather abort itself or break into the debugger. 
> 
> 2. is what Eiffel programs do, but the compiler does not check
> the presence of exception handlers for postconditions that
> may fail (and thus raise an exception).  If it did, will it not
> mean exception handlers pretty much everywhere?

No. Exceptions are supposed to propagate. A propagating exception is
unhandled one.

If you confuse 1 and 2 you get troubles. Another example from Ada is
Program_Error, e.g. from Initialize/Finalize/Adjust. It is meaningless and
very harmful. If you are in 2, it is too LATE to raise anything.

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

Re: Ada requires too much typing!

[BrianG]

Jeffrey R. Carter wrote:
> Peter C. Chapin wrote:
>>
>> However, the argument that I see some people putting forth on the 
>> Scala group
>> is that conciseness is good because it saves typing. I really can't
>> understand that. How hard is it to type?
> 
> The important point is that in the real world, code is written once, but 
> read many times. I'm sure this is just as true with Scala as it is with 
> every other language. So saving typing at the cost of making it harder 
> to read is a false economy. Any project where money is involved should 
> take that into consideration.
> 
> As Preben Randhol put it, "Saving keystrokes is the job of the text 
> editor, not the programming language."
> 
Forget text editors, saving keystrokes is the job of the computer.  And 
I've got just the computer for "Rex":  a Sinclair ZX-81.  Each key on 
the (chicklet) keyboard has a (BASIC) keyword.  Rather than typing out 
G-O-T-O, you only type G and the computer fills in the rest.  It's also 
context-sensitive, so you get the minimum typing to get the program you 
want (as long as you're not an experienced typer and type out the 
keywords anyway).

Better yet - a computer I used in college had a hexadecimal keyboard, 
where you typed in machine code.  Think of it:  no verbosity, no 
"comments", no carriage returns; just raw hex.  What could be more 
"efficient"?

--Bg
-- If writing programs were more important than reading them, we'd be 
programming with invisible ink.  We wouldn't need a monitor.  We 
wouldn't need to save the source code - compile it and you have the 
executable/object, what more do you need?

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Sat, 29 May 2010 20:49:09 -0400, BrianG wrote:

> -- If writing programs were more important than reading them, we'd be 
> programming with invisible ink.

Mean this:

http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29

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

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Sun, 30 May 2010 09:27:58 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> -- If writing programs were more important than reading them, we'd be
>> programming with invisible ink.
>
> Mean this:
>
> http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29

I like the quote on the homepage:
http://compsoc.dur.ac.uk/whitespace/

> What are the advantages of Whitespace?
>
> Some things which are difficult in other languages are made much
> easier in Whitespace. For example, literate programming is simply a
> matter of writing your helpful comments in between program
> instructions.
Dear friends, we have our UML killer.

Have a Merry Christmas

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

>> What are the advantages of Whitespace?
>>
>> Some things which are difficult in other languages are made much
>> easier in Whitespace. For example, literate programming is simply a
>> matter of writing your helpful comments in between program
>> instructions.

I see there is an Emacs mode -- life is complete

http://compsoc.dur.ac.uk/whitespace/tools.php

Re: Ada requires too much typing!

[Luis Espinal]

In article <hto4st$7g2$1@news.eternal-september.org>, Alex R. Mosteo says...
>
>Luis Espinal wrote:
>
>>(...)
>> We have also come to learn that interfaces, the prohibition of multiple
>> inheritance, (...) were not a good idea at all.
>
>Thanks for the elaborate reply. Not expert in Scala/Java so I can't comment 
>about most of it.
>
>However, seeing that Ada has just copied Java interfaces, I'd like to known 
>a bit more in detail why you say what I quoted, if you have the time. I have 
>used interfaces a bit and indeed have some grudges with them, but I'd like 
>to know if the situation is worse than I think -- or perhaps I'm not using 
>them 100% properly.
>
>Thanks in advance,
>
>Alex.

Hi Alex - sorry I didn't reply sooner. I've been on the grind at work in the
last couple of days.

The issue with interfaces (which is not universally accepted among Java
developers) is that they cannot be changed without incurring in changes to
classes implementing that interface. This is a big issue for the way in which
code is developed in Java. Let me try to illustrate:

The common practice in Java is find a platform or framework (some sort of
high-level "virtual" OS for lack of a better word.) Then, either write your apps
on it, or develop another platform on top of it (another, more refined, more
business-specific "virtual" OS. So pretty much we (try to) gradually refine the
architecture of an application via an architecture pre-defined by the runtime
below it. Examples of this are JEE, Spring and the Eclipse framework (and all
the stuff + the kitchen sink that we throw on top of them.)

All those layers are typically defined with interfaces (since we don't get
multiple inheritance or mixin/traits). We end up with these long class
hierarchies, and lots and lots of artifacts implementing lots and lots of
interfaces. Libraries and libraries, and platforms and platforms... without a
concept of versions.

So for example, you have an interface named A that defines a method foo():

public interface A { public void foo(); }

And then you have a large number of classes implementing A, which are
distributed to 3rd parties. A while later, you find you must include a new
method on interface A:

public interface A { public void moo(); }

The moment you do that, you render every library that depended on old A
unusable. Either your clients won't be able to compile it, or if they will get
nasty run-time errors. The JVM will even refuse to load the old classes because
they do not conform with the new interface anymore.

The folks in the eclipse framework, for example, have had to deal with this
problem by implementing "versioned" interfaces and have code deal with them at
run-time:

public interface A { public void foo(); }
public interface A_1 { public void moo(); }

class clientOfA {
  void dooFooAndMaybeMoo( A someA )
  {
     ...
     if( someA instanceof A_1 )
     {
       ((A_1)someA).moo();
     }
     ...
  }  

This could get out of hand (specially with sloppy programmers which, in Java,
unfortunately we have too many.) This can also be a concern with people that
develop frameworks and libraries for both external and internal use. So what we
do is that, in addition to implementing an interface, we typically extend a an
abstract base class that can insulate us from possible changes to the interface:

public interface A {...}
public abstract class AbstractA implements A {...}
public class ConcreteA extends AbstractA {...}

If we need to change A, we simply change AbstractA so that clients of A that
extend AbstractA don't get forced to change their source... but that doesn't do
anything for those that still extend A directly. And having an abstract base
class like that defeats the purpose of being able of creating arbitrary
implementations of an interface.

Other folks deal with that problem by creating Adapters... ending up with a soup
of design patterns going wild.

Some people still think this is still a better trade-off over C++ styled
multiple inheritance because of the dreaded "diamond" problem. To me (and this
is strictly a personal opinion), it isn't.

That's a lot of manual shamanism that should be better dealt with syntactically.
We should have had multiple implementation inheritance from the get-go and just
deal with it using the tools of the language and careful planning.

I think the Scala guys had the most wonderful of ideas by implementing Traits.
They offer many of the benefits of interfaces while simplifying the ability of
inheriting multiple implementations. The focus is no longer on building behavior
not just with inheritance but also with composition. I don't need to worry if my
object is a-something to that can do a-task; I just have to worry that it can
perform the task.

I do think that interfaces have been great for specifying contracts. They
enforce an order on things. However, it is important to plan ahead regarding
interface versions. I don't know if this is a big deal in Ada-land, but in the
JVM-land, it has been.

Please take it with a grain of salt. It is simply my observation, and with
software YMMV from one context to another :)

- Luis Espinal (luis.espinal@gmail.com)

Re: Ada requires too much typing!

[BrianG]

Simon Wright wrote:
> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> 
>>> What are the advantages of Whitespace?
>>>
>>> Some things which are difficult in other languages are made much
>>> easier in Whitespace. For example, literate programming is simply a
>>> matter of writing your helpful comments in between program
>>> instructions.
> 
> I see there is an Emacs mode -- life is complete
> 
> http://compsoc.dur.ac.uk/whitespace/tools.php

But what about a translator to-from Ada?
Could you 'polyglot' the same program for added security? :-)

--IN A WORLD WHERE I FEEL SO SMALL,
-- I CAN'T STOP THINKING BIG.

Re: Ada requires too much typing!

[Alex R. Mosteo]

Luis Espinal wrote:

> In article <hto4st$7g2$1@news.eternal-september.org>, Alex R. Mosteo
> says...
>>
>>Luis Espinal wrote:
>>
>>>(...)
>>> We have also come to learn that interfaces, the prohibition of multiple
>>> inheritance, (...) were not a good idea at all.
>>
>>Thanks for the elaborate reply. Not expert in Scala/Java so I can't
>>comment about most of it.
>>
>>However, seeing that Ada has just copied Java interfaces, I'd like to
>>known a bit more in detail why you say what I quoted, if you have the
>>time. I have used interfaces a bit and indeed have some grudges with them,
>>but I'd like to know if the situation is worse than I think -- or perhaps
>>I'm not using them 100% properly.
>>
>>Thanks in advance,
>>
>>Alex.
> 
> Hi Alex - sorry I didn't reply sooner. I've been on the grind at work in
> the last couple of days.
> 
> The issue with interfaces (which is not universally accepted among Java
> developers) is that they cannot be changed without incurring in changes to
> classes implementing that interface. This is a big issue for the way in
> which code is developed in Java. Let me try to illustrate:

Hi Luis, thanks for the detailed reply. I understand your points clearly.

My days of Java are a bit behind so I'm not sure what I'm about to say can 
be done in Java. In Ada, one could extend an interface adding a new method 
like this:

procedure Moo (This : A) is null;

And effectively it won't break any client, since it provides a default "no-
op" implementation. It won't work for functions, obviously. In any case, 
clients would need to recompile, since in Ada land we're not talking of a 
world of JVMs and dynamic hot-plugging, I presume. This alone (the use of 
stand-alone executables) may make the problem much less of an issue.

Also, not needing to specify defaults to overload a method could be of help?

procedure Foo (This : A) is abstract; -- Added in 1st spec

procedure Foo (This : A; Bar : A'Class) is null; -- Added in 2nd spec

I've done sometimes the thing of having a insulating base class providing 
some/most of the interface core functionality, but at the same time I 
realized that this defeats to some degree the point of interfaces, since you 
can't inherit from two such base classes.

In any case I feel your pain about the lot of Java programmers and 
frameworks ;-) I guess it has its goods and its bads.

Alex.

> 
> The common practice in Java is find a platform or framework (some sort of
> high-level "virtual" OS for lack of a better word.) Then, either write
> your apps on it, or develop another platform on top of it (another, more
> refined, more business-specific "virtual" OS. So pretty much we (try to)
> gradually refine the architecture of an application via an architecture
> pre-defined by the runtime below it. Examples of this are JEE, Spring and
> the Eclipse framework (and all the stuff + the kitchen sink that we throw
> on top of them.)
> 
> All those layers are typically defined with interfaces (since we don't get
> multiple inheritance or mixin/traits). We end up with these long class
> hierarchies, and lots and lots of artifacts implementing lots and lots of
> interfaces. Libraries and libraries, and platforms and platforms...
> without a concept of versions.
> 
> So for example, you have an interface named A that defines a method foo():
> 
> public interface A { public void foo(); }
> 
> And then you have a large number of classes implementing A, which are
> distributed to 3rd parties. A while later, you find you must include a new
> method on interface A:
> 
> public interface A { public void moo(); }
> 
> The moment you do that, you render every library that depended on old A
> unusable. Either your clients won't be able to compile it, or if they will
> get nasty run-time errors. The JVM will even refuse to load the old
> classes because they do not conform with the new interface anymore.
> 
> The folks in the eclipse framework, for example, have had to deal with
> this problem by implementing "versioned" interfaces and have code deal
> with them at run-time:
> 
> public interface A { public void foo(); }
> public interface A_1 { public void moo(); }
> 
> class clientOfA {
>   void dooFooAndMaybeMoo( A someA )
>   {
>      ...
>      if( someA instanceof A_1 )
>      {
>        ((A_1)someA).moo();
>      }
>      ...
>   }
> 
> This could get out of hand (specially with sloppy programmers which, in
> Java, unfortunately we have too many.) This can also be a concern with
> people that develop frameworks and libraries for both external and
> internal use. So what we do is that, in addition to implementing an
> interface, we typically extend a an abstract base class that can insulate
> us from possible changes to the interface:
> 
> public interface A {...}
> public abstract class AbstractA implements A {...}
> public class ConcreteA extends AbstractA {...}
> 
> If we need to change A, we simply change AbstractA so that clients of A
> that extend AbstractA don't get forced to change their source... but that
> doesn't do anything for those that still extend A directly. And having an
> abstract base class like that defeats the purpose of being able of
> creating arbitrary implementations of an interface.
> 
> Other folks deal with that problem by creating Adapters... ending up with
> a soup of design patterns going wild.
> 
> Some people still think this is still a better trade-off over C++ styled
> multiple inheritance because of the dreaded "diamond" problem. To me (and
> this is strictly a personal opinion), it isn't.
> 
> That's a lot of manual shamanism that should be better dealt with
> syntactically. We should have had multiple implementation inheritance from
> the get-go and just deal with it using the tools of the language and
> careful planning.
> 
> I think the Scala guys had the most wonderful of ideas by implementing
> Traits. They offer many of the benefits of interfaces while simplifying
> the ability of inheriting multiple implementations. The focus is no longer
> on building behavior not just with inheritance but also with composition.
> I don't need to worry if my object is a-something to that can do a-task; I
> just have to worry that it can perform the task.
> 
> I do think that interfaces have been great for specifying contracts. They
> enforce an order on things. However, it is important to plan ahead
> regarding interface versions. I don't know if this is a big deal in
> Ada-land, but in the JVM-land, it has been.
> 
> Please take it with a grain of salt. It is simply my observation, and with
> software YMMV from one context to another :)
> 
> - Luis Espinal (luis.espinal@gmail.com)

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Tue, 01 Jun 2010 23:30:54 +0200, Luis Espinal <Luis_member@newsguy.com>  
a écrit:
> The common practice in Java is find a platform or framework (some sort of
> high-level "virtual" OS for lack of a better word.) Then, either write  
> your apps
> on it, or develop another platform on top of it (another, more refined,  
> more
> business-specific "virtual" OS. So pretty much we (try to) gradually  
> refine the
> architecture of an application
Is it one of the reason why Java is virtual machine based ? is it related  
to this process or not ?


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Thu, 03 Jun 2010 18:54:57 +0200, Colin Paul Gloster  
<Colin_Paul_Gloster@acm.org> a écrit:

Box design: (c) Peter C. Chapin.
+---------------------------------------------------------+
| " Passing a parameter to an Ada subprogram can look     |
| like choosing an element of an Ada array, with a very   |
| different execution cost. "                             |
+---------------------------------------------------------+
That's another area and not part of language semantic (readability refers  
to meaning, semantic).

And you will nor see difference of execution cost between two different  
functions.


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Thu, 03 Jun 2010 18:09:38 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Box design: (c) Colin Paul Gloster.
(was confused with names)


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Colin Paul Gloster]

On Wed, 26 May 2010, Peter C. Chapin sent:

|-----------------------------------------------------------------------------|
|"[..]                                                                        |
|                                                                             |
|[..]                                                                         |
|[..] Not surprisingly the Scala community,                                   |
|as evidenced by the posts on a Scala newsgroup, regard conciseness as an     |
|important feature for a programming language. I agree that conciseness can in|
|some cases improve readability. However, I also believe that it can obscure a|
|lot of important detail and make it hard to understand the execution cost of |
|the code. [..]"                                                              |
|-----------------------------------------------------------------------------|

Passing a parameter to an Ada subprogram can look like choosing an
element of an Ada array, with a very different execution cost.

|-----------------------------------------------------------------------------|
|"[..]                                                                        |
|                                                                             |
|However, the argument that I see some people putting forth on the Scala group|
|is that conciseness is good because it saves typing. I really can't          |
|understand that. How hard is it to type?                                     |
|                                                                             |
|[..]"                                                                        |
|-----------------------------------------------------------------------------|

Not very.

Re: Ada requires too much typing!

[Nicholas Collin Paul de Gloucester]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1558 bytes --]

On Thu, 3 Jun 2010, Yannick Duchêne (Hibou57) sent:

|-----------------------------------------------------------------------|
|"Le Thu, 03 Jun 2010 18:54:57 +0200, Colin Paul Gloster                |
|<Colin_Paul_Gloster@acm.org> a écrit:                                  |
|                                                                       |
|[..]                                                                   |
|+---------------------------------------------------------+            |
|| " Passing a parameter to an Ada subprogram can look     |            |
|| like choosing an element of an Ada array, with a very   |            |
|| different execution cost. "                             |            |
|+---------------------------------------------------------+            |
|[..]                                                                   |
|                                                                       |
|And you will nor see difference of execution cost between two different|
|functions."                                                            |
|-----------------------------------------------------------------------|

Actually, you would. Different functions would have different bodies
would tend to have different execution costs. Aside from that, inlined
functions would tend to cost differently than other functions.

However, I had not been posting re different functions. I posted re
utilizing an array and utilizing a subprogram. These can look
identical but cost very differently.

Re: Ada requires too much typing!

[Nicolas Cóilin Paul de Gloucester]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 540 bytes --]

On Thu, 3 Jun 2010, Yannick Duchêne (Hibou57) sent:

|---------------------------------------|
|"> Box design: (c) Colin Paul Gloster."|
|---------------------------------------|

Nicolas Cóilin Paul de Gloucester to you.

Actually I did not invent it, but thank you for a bit of fun.

|---------------------------------------|
|"(was confused with names)"            |
|---------------------------------------|

Francophones had been historically noted for being confused by names,
not least of all Gaelic names.

Bye,
me

Re: Ada requires too much typing!

[Ludovic Brenta]

Nicolas Cóilin Paul de Gloucester wrote:
> On Thu, 3 Jun 2010, Yannick Duchêne (Hibou57) sent:
>
> |---------------------------------------|
> |"> Box design: (c) Colin Paul Gloster."|
> |---------------------------------------|

This box design is a nuisance to me; I don't want to have to teach
emacs how to fill a boxed paragraph in gnus; M-q fills paragraphs
beginning with most quoting characters (>, !, |, etc.) correctly but
not boxed ones. In Google Groups, boxed paragraphs are ugly when in
proportional font.

> Nicolas Cóilin Paul de Gloucester to you.
>
> Actually I did not invent it, but thank you for a bit of fun.
>
> |---------------------------------------|
> |"(was confused with names)"            |
> |---------------------------------------|
>
> Francophones had been historically noted for being confused by names,
> not least of all Gaelic names.

That's your fault. How many different names or spellings thereof do
you post under? Just in the past 24 hours I've seen variations like:

Colin Paul Gloster
Nicolas Cóilin Paul Gloucester
Nicolas Collin Paul de Gloucester
Nicolas Cóilin Paul de Gloucester
Nicholas Cóilin Paul de Gloucester

So, is your name really a regexp? Is this one in extended syntax
correct?
(Nich?olas)|(C[óo]l?lin) Paul (de)? Glo(uce)?ster

How about just "Paul" which seems to be the only constant?

--
Ludovic Brenta.

Re: Ada requires too much typing!

[Luis Espinal]

In article <hu5e4u$6il$1@news.eternal-september.org>, Alex R. Mosteo says...
>

>
>Hi Luis, thanks for the detailed reply. I understand your points clearly.
>
>My days of Java are a bit behind so I'm not sure what I'm about to say can 
>be done in Java. In Ada, one could extend an interface adding a new method 
>like this:
>
>procedure Moo (This : A) is null;
>
>And effectively it won't break any client, since it provides a default "no-
>op" implementation. It won't work for functions, obviously. In any case, 
>clients would need to recompile, since in Ada land we're not talking of a 
>world of JVMs and dynamic hot-plugging, I presume. This alone (the use of 
>stand-alone executables) may make the problem much less of an issue.
>
>Also, not needing to specify defaults to overload a method could be of help?
>
>procedure Foo (This : A) is abstract; -- Added in 1st spec
>
>procedure Foo (This : A; Bar : A'Class) is null; -- Added in 2nd spec
>
>I've done sometimes the thing of having a insulating base class providing 
>some/most of the interface core functionality, but at the same time I 
>realized that this defeats to some degree the point of interfaces, since you 
>can't inherit from two such base classes.
>
>In any case I feel your pain about the lot of Java programmers and 
>frameworks ;-) I guess it has its goods and its bads.
>
>Alex.
>

That actually seems like a much better implementation of interfaces than Java's.
I think it would have been interesting if Ada interfaces were to provide a
default behavior for function that throws an exception when called. In Java, we
usually have to inherit functions off interfaces for which no appropriate
behavior exist, and thus the usual convention (manually implemented mind you) is
to add a throw UnsuportedOperationException() for those functions.

That'd probably be appropriate for enterprise systems, but not for critical
systems which is probably why it is not implemented in Ada. You are right to
point out that in Ada things compile or do not. In Java we never really know who
is going to dynamically load (or inherit) from artifacts of our making.

- Luis.

Re: Ada requires too much typing!

[Luis Espinal]

In article <op.vdob5ebexmjfy8@garhos>,
=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= says...
>
>Le Tue, 01 Jun 2010 23:30:54 +0200, Luis Espinal <Luis_member@newsguy.co=
>m>  =
>
>a =E9crit:
>> The common practice in Java is find a platform or framework (some sort=
> of
>> high-level "virtual" OS for lack of a better word.) Then, either write=
>  =
>
>> your apps
>> on it, or develop another platform on top of it (another, more refined=
>,  =
>
>> more
>> business-specific "virtual" OS. So pretty much we (try to) gradually  =
>
>> refine the
>> architecture of an application
>Is it one of the reason why Java is virtual machine based ? is it relate=
>d  =
>
>to this process or not ?
>

Not quite Yannick. Originally Java (called Oak then) was intended to run in
certain embedded devices. Having a streamlined virtual machine with a uniform
set of libraries and I/O abstractions would allow the language to run in
multiple architectures. As it evolved, its potential for networked/distributed
systems development became more apparent. All that was occurring at a juncture
when enterprises were moving into the client-server area (and then into
internet-based systems). Java fitted the bill better than what was available
then.

You didn't have to drop your previous investment in AS/400 machines, for
example. You could run your Java apps there, and as you buy new hardware (almost
any type of hardware) when you needed to scale up (again, w/o having to throw
away your previous machinery.)

So basically, the jvm (java virtual machine) was created to allow the java
compiler to spit Java bytecode that would run in any hardware architecture that
had a jvm  written for it.

Now the tables seem to be turning. Java is no longer the target, but the jvm and
the bytecode that it runs that are the target. People are now developing new
languages for the jvm (and for .NET clr, Window's vm), languages that provide
better programming facilities than Java. Scala is one example. The promise is
also to have the same exact bytecode (or at least have the same source code
compiled) running on both jvm and .NET clr. Google is implementing a different
java virtual machine called Dalvik for the android platform. Dalvik's is
register based whereas Sun's is stack-based.

Not to belittle Java's contribution, but it seems that in the long run, Sun's
long lasting legacy will be its Java virtual machine instead of the Java
language itself.

- Luis.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Sat, 05 Jun 2010 22:13:46 +0200, Luis Espinal <Luis_member@newsguy.com>  
a écrit:
> You didn't have to drop your previous investment in AS/400 machines, for
> example. You could run your Java apps there, and as you buy new hardware  
> (almost
> any type of hardware) when you needed to scale up (again, w/o having to  
> throw
> away your previous machinery.)
OK.

> Google is implementing a different
> java virtual machine called Dalvik for the android platform. Dalvik's is
> register based whereas Sun's is stack-based.
On the margin: I suppose then it will use a kind of “link register” for  
recursivity and a kind of “local data pointer register” for locals (funny).

> Not to belittle Java's contribution, but it seems that in the long run,  
> Sun's
> long lasting legacy will be its Java virtual machine instead of the Java
> language itself.
>
> - Luis.
That is indeed what I feel I have understood after this thread (just  
wonder how SUN will react in the future, ... I mean, economically, as this  
is most of time a matter also)


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Martin Krischik]

Am 28.05.2010, 07:25 Uhr, schrieb Luis Espinal <Luis_member@newsguy.com>:

> I don't think that is much of an issue. Mutability is. This is a big  
> issue for
> Java as it has turned out. The commonly accepted best practice now is to  
> mark
> variables and parameters as final unless you know before hand that you  
> want to
> change them.

Which only makes the reference to the variable un-mutable, not the  
content. That combined with language which can do only pass by reference  
for all complex types and a Clonable interface which was badly sorted out  
gives you a language where the protection a getter function should give  
you is just not there - unless you make it a habit to use «return x.clone  
()» [1].

And if we are at it - setter functions should use «this.x = x.clone ()».  
Those who did Ada or C++ know that. In Ada setter and getter functions  
usually take a copy and in C++ setter and getter functions take a  
reference to a constant object. That is: not the reference is constant -  
the object itself is constant (un-mutable).

As it is most setter and getter functions in Java are placebos - they give  
you you the feeling to do it the proper OO way but you are don't!

Martin

[1] provided the class at hand implements the Clonable interface property  
and does indeed do full deep copy.
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Martin Krischik]

Hi Luis,

Am 01.06.2010, 23:30 Uhr, schrieb Luis Espinal <Luis_member@newsguy.com>:

> Some people still think this is still a better trade-off over C++ styled
> multiple inheritance because of the dreaded "diamond" problem.

which is easily solved by marking classes virtual. One should just make a  
habit of defining classes like this:

virtual Base
   {
   public:
     virtual ~Base ()
       {
       …
       }
   }

And suddenly all your virtual inheritance needs work flawlessly. There are  
just too many C++ programmers out there who do not know that.

> That's a lot of manual shamanism that should be better dealt with  
> syntactically.

As I mentioned before: true Shamans (yes they still exists, mostly  
Siberia) work a lot with poisonousness substances. If they make a mistake  
then either they or there customers end up dead. Comparing computer  
science with shamans is an insult to the professional work of shamans.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Simon Wright]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> One should just
> make a habit of defining classes like this:
>
> virtual Base
>   {
>   public:
>     virtual ~Base ()
>       {
>       …
>       }
>   }
>
> And suddenly all your virtual inheritance needs work flawlessly.

I suppose there must be some cost to doing this? or the language
definition would require it to be always so.

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Sun, 06 Jun 2010 11:13:46 +0100, Simon Wright wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> writes:
> 
>> One should just
>> make a habit of defining classes like this:
>>
>> virtual Base
>>   {
>>   public:
>>     virtual ~Base ()
>>       {
>>       嚙皺
>>       }
>>   }
>>
>> And suddenly all your virtual inheritance needs work flawlessly.
> 
> I suppose there must be some cost to doing this? or the language
> definition would require it to be always so.

Yes, in C++. No, in Ada, if Ada supported by-value classes. Since in Ada T
/= T'Class you need not put as in C++ the type tag into the object. You
could put the tag only into T'Class and leave T as is. You would lose view
conversions T <-> T'Class, but they don't have sense for by-value objects
anyway.

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

Re: Ada requires too much typing!

[Martin Krischik]

Am 06.06.2010, 12:13 Uhr, schrieb Simon Wright <simon@pushface.org>:

> "Martin Krischik" <krischik@users.sourceforge.net> writes:
>
>> One should just
>> make a habit of defining classes like this:
>>
>> virtual Base
>>   {
>>   public:
>>     virtual ~Base ()
>>       {
>>       …
>>       }
>>   }
>>
>> And suddenly all your virtual inheritance needs work flawlessly.
>
> I suppose there must be some cost to doing this? or the language
> definition would require it to be always so.

Yes indeed, you have virtual dispatch not only on the methods but on the  
instance variables as well. Sounds worth then it is. It means the internal  
structure of a child type changes from (Ada pseudo code):

record Child_Type is
     Parent_Data : Parent_Type;
end record

to

record Child_Type is
     Hidden_Parent_Data : Parent_Type;
     Parent_Data : constant access Parent_Type := Hidden_Parent_Data'Access;
end record

The compiler will ensure that Hidden_Parent_Data exist only once - but  
there may be any amount of Parent_Data which all point to the same  
Hidden_Parent_Data. And the funny part: The technology used to archive  
this is the very same you use to implement interfaces. Once you have the  
scaffolding for Interfaces in place you can have virtual base classes as  
well.

Main problem with multiple inheritance was in  C++ itself where default is  
“fast” not ”save”. For the Eiffel users it was never a problem because  
there virtual base classes are default. And I just see I made a mistake in  
my original post. It should have been:


class Parent
    {
    public:
      virtual ~Parent ()
        {
        …
        }
    }

class Child
    virtual public Parent
    {
    …
    }

but main problem stay: not enough C++ programmer have known about virtual  
inheritance and the diamond problem only pops up at Grand_Child level and  
lower  (that means one has to plan ahead to avoid it). This in turn given  
multiple inheritance a bad name. But if you do it right it works just  
beautifully.

The real lesson learned: “doing it right” must be default and “make it  
fast” must be an optional extra to be taught in very advanced level  
courses only.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Maciej Sobczak]

On 6 Cze, 10:55, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

> > Some people still think this is still a better trade-off over C++ styled
> > multiple inheritance because of the dreaded "diamond" problem.
>
> which is easily solved by marking classes virtual. One should just make a  
> habit of defining classes like this:
>
> virtual Base
>    {
>    public:
>      virtual ~Base ()
>        {
>        …
>        }
>    }

That will not work. Not just because it is invalid syntax, but because
"virtualness" is a property of the relation between classes, not the
property of any particular class.

> And suddenly all your virtual inheritance needs work flawlessly. There are  
> just too many C++ programmers out there who do not know that.

Not really, see my answer to your other post.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Maciej Sobczak]

On 6 Cze, 14:04, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

> > I suppose there must be some cost to doing this? or the language
> > definition would require it to be always so.
>
> Yes indeed, you have virtual dispatch not only on the methods but on the  
> instance variables as well.

No, such concept does not even make sense - instance variables
themselves have no behavior and therefore cannot be "overriden". With
virtual inheritance there is only one copy of the given instance
variable within the whole object, so even the word "dispatch" cannot
be applied there, as "dispatch" relates to "choice" and there is no
choice.

> Main problem with multiple inheritance was in  C++ itself where default is  
> “fast” not ”save”.

No. Neither of these (non-virtual vs. virtual) is "fast" or "safe" in
itself.

Considering the performance aspect, the layout of variables within the
object is determined *statically* (I have already explained that there
is no "dispatch" involved), which means that there is no run-time cost
in finding the given data item. All instance variables have some
offset from the "beginning" of the object and that offset is computed
statically, whether inheritance is virtual or not. There is no
particular reason for any performance difference in data access, so it
does not make any sense to say than one mode is "fast", while the
other is not. Both are "fast" (it's C++, remember? ;-) ).

Considering the safety aspect, the choice between non-virtual and
virtual is design-dependent. Both make sense in some domain.
For example, my mobile phone is able to send both text and multimedia
messages. In both cases I might want to see the count of messages that
were already sent and I want these counters to be *distinct*, not
shared.
This is a perfectly valid design (pseudo-code):

class Countable;
class TextMessager : public Countable;
class MultimediaMessager : public Countable;
class Phone : public TextMessager, public MultimediaMessager, ...;

Now I have *separate* counters, both accessible with appropriate name
paths (which makes perfect sense).

Why is this a default? I don't know, but it's consistent with the fact
that the whole object model is value-oriented, not interface-oriented.
It's neither right nor wrong.

(note: you might argue that the counter should be held by composition,
not by extension - this is orthogonal to this discussion)

> but main problem stay: not enough C++ programmer have known about virtual  
> inheritance

Again, that knowledge would not necessarily help them, as the use of
virtual inheritance is not automatically justified.

> The real lesson learned: “doing it right” must be default

Both ways are right. The default one is consistent with the overall
object model.

> and “make it  
> fast” must be an optional extra

Both are fast.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Martin Krischik]

Am 07.06.2010, 10:13 Uhr, schrieb Maciej Sobczak  
<see.my.homepage@gmail.com>:

> That will not work. Not just because it is invalid syntax, but because
> "virtualness" is a property of the relation between classes, not the
> property of any particular class.

Read my post below.

Martin

-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Martin Krischik]

Am 07.06.2010, 10:13 Uhr, schrieb Maciej Sobczak  
<see.my.homepage@gmail.com>:

>> And suddenly all your virtual inheritance needs work flawlessly. There  
>> are
>> just too many C++ programmers out there who do not know that.

> Not really, see my answer to your other post.

So you think that all C++ programmers are perfect and know the ISO/IEC  
14882:2003 from memory? Well the amount of C++ programming has reduced in  
recent years - maybe those who work in the business these days are of a  
better quality then those I knew. who knows.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Martin Krischik]

Am 07.06.2010, 10:34 Uhr, schrieb Maciej Sobczak  
<see.my.homepage@gmail.com>:

> On 6 Cze, 14:04, "Martin Krischik" <krisc...@users.sourceforge.net>
> wrote:
>
>> > I suppose there must be some cost to doing this? or the language
>> > definition would require it to be always so.
>>
>> Yes indeed, you have virtual dispatch not only on the methods but on  
>> the instance variables as well.
>
> No, such concept does not even make sense - instance variables
> themselves have no behavior and therefore cannot be "overriden". With
> virtual inheritance there is only one copy of the given instance
> variable within the whole object, so even the word "dispatch" cannot
> be applied there, as "dispatch" relates to "choice" and there is no
> choice.
>
>> Main problem with multiple inheritance was in  C++ itself where default  
>> is “fast” not ”save”.
>
> No. Neither of these (non-virtual vs. virtual) is "fast" or "safe" in
> itself.

There is a difference between x.y and x->y.  I don't care - but the CPU  
cycle counters who designed C++ did.

> Considering the performance aspect, the layout of variables within the
> object is determined *statically* (I have already explained that there
> is no "dispatch" involved), which means that there is no run-time cost
> in finding the given data item. All instance variables have some
> offset from the "beginning" of the object and that offset is computed
> statically, whether inheritance is virtual or not. There is no
> particular reason for any performance difference in data access, so it
> does not make any sense to say than one mode is "fast", while the
> other is not. Both are "fast" (it's C++, remember? ;-) ).

Interesting opinion. Say we have (all lines in different compilation  
units, so no fancy optimizer tricks):

class Parent {public: int x};
class  Child1: public virtual Parent;
class Child2 : public  virtual Parent;
class Incest : public  virtual Child1, public  virtual Child2;

auto Incest* incest = new Incest();
auto Child1* child1 = static_cast <Child1*> (incest);
auto Child2* child2 = static_cast <Child2*> (incest);

So now tell me how the compiler staticly determines:

child1->x;
child2->x;

As a hint, at any time you could do a:

child1=new Child1();
child2=new Child2();

as well.

> Considering the safety aspect, the choice between non-virtual and
> virtual is design-dependent.

>> but main problem stay: not enough C++ programmer have known about  
>> virtual inheritance
>
> Again, that knowledge would not necessarily help them, as the use of
> virtual inheritance is not automatically justified.

Like the use if virtual destructors is not automaticly justified? Only:  
count in your source the amount virtual destructors vs. non virtual  
destructors. Why is what you need most not default? In my C++ time the  
ratio between virtual and non virtual inheritance was similar - and it  
served me well.

>> The real lesson learned: “doing it right” must be default
>
> Both ways are right. The default one is consistent with the overall
> object model.
>
>> and “make it fast” must be an optional extra
>
> Both are fast.

As I said fast enough for me.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Colin Paul Gloster]

On Mon, 7 Jun 2010, Martin Krischik wrote:
|--------------------------------------------------------------|
|"[..]                                                         |
|                                                              |
|[..] Say we have (all lines in different compilation units, so|
|no fancy optimizer tricks):                                   |
|                                                              |
|class Parent {public: int x};                                 |
|class  Child1: public virtual Parent;                         |
|class Child2 : public  virtual Parent;                        |
|class Incest : public  virtual Child1, public  virtual Child2;|
|                                                              |
|auto Incest* incest = new Incest();                           |
|auto Child1* child1 = static_cast <Child1*> (incest);         |
|[..]                                                          |
|                                                              |
|[..]"                                                         |
|--------------------------------------------------------------|

Well maybe if there was a nice sibling, ho ho! Oh, I love Usenet.

Re: Ada requires too much typing!

[Maciej Sobczak]

On 7 Cze, 11:25, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

> > Considering the performance aspect, the layout of variables within the
> > object is determined *statically*
[...]

> Interesting opinion. Say we have
[...]

You are right here, I got confused by the low-level implementation
details.
There must be a run-time component of the access method for instance
variables from virtually inherited classes. Mea culpa.

I will still take the opportunity to twist my mistake :-) - take it as
a proof that I have never explicitly used virtual inheritance in
professionally written code, even though I *have* used multiple
inheritance occasionally.
Guess what - the default mechanisms always worked as I intended - this
might be an indication that the whole problem is not nearly as
dramatic as you portray it.

In other words, I disagree with your statement that the behavior of C+
+ in this area should be different.

> > Again, that knowledge would not necessarily help them, as the use of
> > virtual inheritance is not automatically justified.
>
> Like the use if virtual destructors is not automaticly justified?

That's right.

> Only:  
> count in your source the amount virtual destructors vs. non virtual  
> destructors.

OK. Let's take something publicaly verifiable: the YAMI4 project,
which contains some amount of C++ code (analyzed header files):
- All destructors: 28
- Virtual ones   : 6

Let's take the SOCI project for comparison:
- All destructors: 61
- Virtual ones   : 20

It looks like virtual destructors amount for some 20-30% of all in my
code.

> Why is what you need most not default?

I find that what C++ offers in this area is what I need most of the
time.
Now I even have the scientific and statistical proof for this, as
before this discussion I did not even know the real numbers. :-)

I don't claim that my experiences are representative, but I will take
the risk to claim that if you need all or most of your destructors to
be virtual, then you are probably trying to write Java in C++.

Now, to bring this discussion at least a bit back on topic, I think
that Ada could offer similar mechanisms as C++. The reason is that the
object model in both languages is very similar and in both cases based
on value semantics. In particular, I find it a nuisance that
controlled types must be tagged.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Mon, 7 Jun 2010 05:17:16 -0700 (PDT), Maciej Sobczak wrote:

> In particular, I find it a nuisance that
> controlled types must be tagged.

Ditto, types where a class may root.

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

Re: Ada requires too much typing!

[Martin Krischik]

Am 07.06.2010, 14:17 Uhr, schrieb Maciej Sobczak  
<see.my.homepage@gmail.com>:

> It looks like virtual destructors amount for some 20-30% of all in my
> code.

Now that is interesting. It means that most of your classes are final as  
the java guys would say. While I have always written under the premises  
that my classes might become child classes for something else.

BTW: you are aware that if the parent class uses a virtual destructor then  
the child class does as well - even when not explicitly specified?

> then you are probably trying to write Java in C++.

I learned C++ before Java using IBM Open Class Library  
«http://en.wikipedia.org/wiki/IBM_Open_Class». Probably more then anything  
the OCL influenced my OO thinking. A string class with lazy copy, a great  
collection class which (optionality) implemented the observer notifier  
pattern, a database persistence object layer. Well and 90% of the classes  
descending form IVBase. Guess what the V stands for.

There is a class overview here

http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%5CIBMVACPP%5CCPPCLRF.INF

or here:

http://caligari.dartmouth.edu/doc/ibmcxx/en_US/doc/hgref.htm

And yes the OCL shares a lot with Java. The single base class for example,  
or a toString method for every class, or the use of interfaces.

Martin

-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Luis Espinal]

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

In article <op.vdvcs3b5z25lew@macpro-eth1.krischik.com>, Martin Krischik says...
>
>Am 28.05.2010, 07:25 Uhr, schrieb Luis Espinal <Luis_member@newsguy.com>:
>
>> I don't think that is much of an issue. Mutability is. This is a big  
>> issue for
>> Java as it has turned out. The commonly accepted best practice now is to  
>> mark
>> variables and parameters as final unless you know before hand that you  
>> want to
>> change them.
>
>Which only makes the reference to the variable un-mutable, not the  
>content. 

Yes. Absolutely and you are right. I think I should say that comment is wrt of
Java default behavior towards variable/parameter declarations vs Scala's. So,
what we are referring to here is not so much immutability of class instances
(which would be the ideal... see below), but immutability of values and
arguments within expressions (a practical concession given the limits of the
language).

The argument here is values that are immutable (either manually as in Java or by
default as in Scala) leads to writing code based (or mostly based) on
expressions. When done properly, it tends to be succinct and yet readable.

>That combined with language which can do only pass by reference  
>for all complex types and a Clonable interface which was badly sorted out  
>gives you a language where the protection a getter function should give  
>you is just not there - unless you make it a habit to use «return x.clone  
>()» [1].
>

It's not just Cloneable that we have to deal with. It's also when implementing
Serializable. Or forced to rely on automatic garbage collection without having
reliable finalizer methods. Not having the C++ equivalent of const member
functions and const return types can be quite hurtful, too.

>And if we are at it - setter functions should use «this.x = x.clone ()».  
>Those who did Ada or C++ know that. In Ada setter and getter functions  
>usually take a copy and in C++ setter and getter functions take a  
>reference to a constant object. That is: not the reference is constant -  
>the object itself is constant (un-mutable).
>

You are going to have forgive my C++/Ada peasantry since I haven't touched
either for more than a decade (since I left grad school.) Why exactly would we
want (in Java) to return a clone wrt to a setter/getter?

I could understand *that* in C++ wrt to implementing a getter for an entity "A"
that returns a modifiable copy/clone of "A". But in Java (where we have no
guarantees when an object is going to be reclaimed), we simply cannot do that.

By default, we have to assume that if a getter returns a reference to an
instance of a class that is not immutable (.ie. extensions of java.lang.Number
or String), then we have the ability to modify it (while still being part of the
enclosing class exposing the getter method.)

That's the default modus operandi. Anything else (returning a deep or shallow
clone, for instance) has to be explicitly documented.

As you pointed out,  however, a good and valid criticism can be made on Java
regarding 1) passing everything by value and 2) working with object references
only. Without having the C++ equivalent of const member functions and const
return types, it is impossible to syntactically enforce immutability. We can
only do so in Java by convention and by structuring our classes as either
mutable and immutable (the later being Scala's route.)

>As it is most setter and getter functions in Java are placebos - they give  
>you you the feeling to do it the proper OO way but you are don't!
>
>Martin
>
>[1] provided the class at hand implements the Clonable interface property  
>and does indeed do full deep copy.

I'm not sure I follow here either. I'm saying this genuinely, and I'd be happy
to see your POV on this subject.

To me a chain of calls P.getQ.getR...X.getY.getZ is simply a chain of messages
from the caller to an given entity(Z) all the way through different contexts.
The accessed attribute can be very primitive or complex, mutable or immutable,
all that depending on the nature of the message and the nature of the receiving
entity. That is, its complexity (or lack thereof) is implementation-specific,
and thus hidden by these getter and setter methods.

Whether it is immutable or if it permits mutability of one or all of its
attributes, that's specific of the entity's public interfaces. I'd grant that it
will be better, more syntactic, finer grained way of controlling mutability, but
its presence is not necessarily required for object-orientation.


I won't argue, however, the sad fact a lot of people in Java don't understand
that, and they end up simulating goto-based programming with their poorly
constructed classes :)

- Luis Espinal. luis.espinal@gmail.com

ps... I'll add to the discussion that one thing we sorely miss in Java is the
ability to write nested functions as in Ada, Pascal and ALGOL. IMO they lead to
cleaner, more organized code.

Re: Ada requires too much typing!

[Martin Krischik]

Am 07.06.2010, 20:30 Uhr, schrieb Luis Espinal <Luis_member@newsguy.com>:

> In article <op.vdvcs3b5z25lew@macpro-eth1.krischik.com>, Martin Krischik  
> says...
> Not having the C++ equivalent of const member
> functions and const return types can be quite hurtful, too.

cost is a reserved word in Java. That's for future use as keyword. So is  
goto ;-).

>
>> And if we are at it - setter functions should use «this.x = x.clone  
>> ()».
>> Those who did Ada or C++ know that. In Ada setter and getter functions
>> usually take a copy and in C++ setter and getter functions take a
>> reference to a constant object. That is: not the reference is constant -
>> the object itself is constant (un-mutable).
>>
>
> You are going to have forgive my C++/Ada peasantry since I haven't  
> touched
> either for more than a decade (since I left grad school.) Why exactly  
> would we
> want (in Java) to return a clone wrt to a setter/getter?

I thing this example should explain it:

java.util.ArrayList evilChange = someInstance.getPreciousList ();

evilChange.clear();

O course retuning a const would protect just as good and render better  
performance.

Having immutable object like java.lang.String helps as well.

> By default, we have to assume that if a getter returns a reference to an
> instance of a class that is not immutable (.ie. extensions of  
> java.lang.Number
> or String), then we have the ability to modify it (while still being  
> part of the
> enclosing class exposing the getter method.)

In Java. Most other OO languages see that differently. The OO principle is  
the the internal state of a class can only be changed true a setter. If I  
have a state called preciousList you should not be able to change  
preciousList using getPreciousList(). You should do so be using  
setPreciousList(), setPreciousList(int) or appendPreciousList().

Why? For example my class states are usually bound. If you get the list  
and change it behind my back the observers are never notified of change.  
The hole observer/notifier pattern collapses. And with it the  
model/view/controller pattern. And eh voila what is shown in the view is  
not what is stored data access object and a difficult to find bug in the  
middle.

> That's the default modus operandi. Anything else (returning a deep or  
> shallow clone, for instance) has to be explicitly documented.

This in my eye is turning a fault into a virtue.

> only do so in Java by convention and by structuring our classes as either
> mutable and immutable (the later being Scala's route.)

immutable data access objects?

>> As it is most setter and getter functions in Java are placebos - they  
>> give
>> you you the feeling to do it the proper OO way but you are don't!

> I'm not sure I follow here either. I'm saying this genuinely, and I'd be  
> happy to see your POV on this subject.
>
> To me a chain of calls P.getQ.getR...X.getY.getZ is simply a chain of  
> messages
> from the caller to an given entity(Z) all the way through different  
> contexts.

That's ok. What I argue is that the following should not be allowed:

P.getQ.setR(…)

It should be:

q = P.getQ
q.setR(…);
p.setQ(q);

And the simplest of all examples are bound properties (that's  
observer/notifier pattern for non Java developers). If you do the first  
then the observers of P are not notified. of the change to Q.  I would not  
be surprised if observer/notifier was considered an anti pattern in Java  
[1]. That again would be turning a fault into a virtue. Observer /  
Notifier worked marvellously great in the IBM open class (C++).

> ps... I'll add to the discussion that one thing we sorely miss in Java  
> is the
> ability to write nested functions as in Ada, Pascal and ALGOL. IMO they  
> lead to
> cleaner, more organized code.


int f ()
    {
    class c
    {
       int g ()
          {
          …
          };
    }

    c i = new c();

    return i.g();
}


just about as painful as using local packages to add static variables to  
Ada procedures.

Martin

[1] Like the singleton pattern. I read the rationale why singleton is  
considered an anti pattern and it was all about Java quirks which do not  
apply to Ada or C++. Still the Java advocates cry “anti pattern”. For me  
anti pattern need to be anti pattern in all (or at least most) programming  
languages.

PS: I am doing my SCJD  right now. I think the assignment has been  
specificity designed to make you hate Java. Or maybe I should not have  
chosen rmi over socket communication after all...

-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Georg Bauhaus]

On 6/8/10 8:43 AM, Martin Krischik wrote:

>  using local packages to add static variables to
> Ada procedures.

OTOH, I'd think a static local variable is most useful if and only
if two condition are true

- there is a single library level procedure operating
on the variable, not two (otherwise a package contains both
of them), and

- the variable's subtype does not depend on the procedure

Is this true?  Can you give a few use cases?

Re: Ada requires too much typing!

[Maciej Sobczak]

On 7 Cze, 17:00, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

> > It looks like virtual destructors amount for some 20-30% of all in my
> > code.
>
> Now that is interesting.

It's even more interesting than this, because in several cases I had
to add the "virtual" keyword not because it was driven by design, but
because the compiler complained about the lack of it. The g++ compiler
gives a warning (-Wall) for each case where a class has at least one
virtual function and non-virtual destructor.
That is, in order to get a clean compile, I had to add the "virtual"
keyword in several places where it was not necessary from the design
point of view.

In other words, the effective numbers are even lower than that.

> It means that most of your classes are final as  
> the java guys would say. While I have always written under the premises  
> that my classes might become child classes for something else.

(rather parent classes, or to use the C++ terminology - base classes)

In many projects classes can be divided into two groups:

1. "public", making a user API of the project (typical for libraries)
2. "private", for the implementation details

The types from the first group *might* become parents for something
provided by the user and it makes sense to defensively prepare them
for this role. Even this is not always the case, for example *none* of
the STL classes has a virtual destructor.

Types from the second group are fully controlled by the project
designer - this includes the closure of eventual hierarchy and all
usage patterns. If instances of these types are not deleted by pointer
to base then there is *no reason* to make their destructors virtual.

And I try to avoid using pointer if they are not necessary.

Note: if the project is not a library, then the first group is empty.

> BTW: you are aware that if the parent class uses a virtual destructor then  
> the child class does as well - even when not explicitly specified?

I am pedantic in my coding conventions and I always mark virtual stuff
as being explicitly virtual.

> > then you are probably trying to write Java in C++.
>
> I learned C++ before Java using IBM Open Class Library

In other words, you have been exposed to the overly object-oriented
style. :-)
Try some modern libraries like Boost or POCO - they are a lot less
focused on object orientation.
  
> A string class with lazy copy,

C++ library authors resigned from this idea long time ago. It's very
ineffective in the multithreading environment.

> Well and 90% of the classes  
> descending form IVBase. Guess what the V stands for.

As I've already said - this design approach is representative for
'80s. There is a reason for why today's most acknowledged libraries
are not designed this way.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Martin Krischik]

Am 08.06.2010, 09:46 Uhr, schrieb Maciej Sobczak  
<see.my.homepage@gmail.com>:

> In other words, you have been exposed to the overly object-oriented
> style.

And how is that any better then the over templatized way used today?

> As I've already said - this design approach is representative for
> '80s. There is a reason for why today's most acknowledged libraries
> are not designed this way.

Yes, but it's speed over everything again. This is why the why the STL  
“classes” have no virtual destructor. vector<> had to be as fast as the  
build in array. And the rest of the STL has been designed from there. Any  
design compromise acceptable as long as speed is not compromised.

I don't like the STL much. The reason is that foremost I see myself as an  
OO programmer and the language is just a tool. I have done OO on C -  
including inheritance and virtual dispatch. For me an object must support  
inheritance and the STL does not. Therefore the STL is just a collections  
of utilities outside the OO framework.

Reading the rest of you post I wonder if C++ has given up on being an  
object orientated language? Perhaps becoming a generic (metaprogramming)  
language instead.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Martin Krischik]

Am 08.06.2010, 09:10 Uhr, schrieb Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de>:

> Is this true?  Can you give a few use cases?

I was not thinking semantic or design level. Just syntactic similarities:


int f ()
    {
    class c
    {
       int g ()
          {
          …
          };
    }

    c i = new c ();

    return i.g ();
}

vs.

function f returns Integer

   package i is
     g : Integer := 0;
   end i;

begin
   i.g := i.g + 1;
   return i.g;
end f;

As said just the boilerplate code is what I found amusing, paint-full and  
kind of similar.

Martin

-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Ada requires too much typing!

[Niklas Holsti]

Martin Krischik wrote:

> just about as painful as using local packages to add static variables to 
> Ada procedures.

Later Martin Krischik wrote:

 > function f returns Integer
 >
 >   package i is
 >     g : Integer := 0;
 >   end i;
 >
 > begin
 >   i.g := i.g + 1;
 >   return i.g;
 > end f;

If you mean the latter code to be an example of the former task (add 
static variable), I believe you are mistaken.

The variable f.i.g is not "static" in the sense of being statically 
allocated. The nested package i is elaborated on each invocation of 
function f, which means that f.i.g is stack allocated, initialized to 0 
on each invocation of f, then incremented to 1. Thus f always returns 1.

To make a statically allocated variable, you need a library package. 
Perhaps you are thinking of the technique suggested by Mark Lundquist, 
at http://www.adapower.com/index.php?Command=Class&ClassID=Basics&CID=204

That technique uses a nested package inside a library package, but not 
within the subprogram using the variable. The nesting is used only to 
hide the variable from other subprograms that are in the same library 
package but are not in the nested package.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada requires too much typing!

[Georg Bauhaus]

On 08.06.10 12:10, Niklas Holsti wrote:
> Martin Krischik wrote:
> 
>> just about as painful as using local packages to add static variables
>> to Ada procedures.
> 
> Later Martin Krischik wrote:
> 
>> function f returns Integer
>>
>>   package i is
>>     g : Integer := 0;
>>   end i;
>>
>> begin
>>   i.g := i.g + 1;
>>   return i.g;
>> end f;
> 
> If you mean the latter code to be an example of the former task (add
> static variable), I believe you are mistaken.

I thought, too, that a new variable decl inside the local package
would still be elaborated each time. The initilization of g
confirms when tested.

But then I thought, surprise!, doubted everything I thought
I had learned about Ada. Looking at this:

with Ada.Text_IO;  use Ada.Text_IO;

procedure Sttc is

   type T is range 0 .. 10;

   procedure A is
      package P is  -- local package
         V: T;    -- presumably static?
      end P;
   begin
      if P.V'Valid then
         P.V := P.V + 1;
      else
         P.V := T'First;
      end if;
      Put_Line (T'Image(P.V));
   end A;

begin
   A; A; A;
end Sttc;


$ ./sttc
 0
 1
 2
 3
$

Compiled with or without -gnatVa.  But this seems to be accidental,
V is just a variable that isn't initialized, living on the stack.
Confirmation:

with Ada.Text_IO;  use Ada.Text_IO;

procedure Sttc is

   type T is range 0 .. 10;

   procedure A is
      package P is
         V: T;
      end P;
   begin
      if P.V'Valid then
         P.V := P.V + 1;
      else
         P.V := T'First;
      end if;
      Put_Line (T'Image(P.V));
   end A;

   procedure Ovrwrt_Stk  is
      X : T;
   begin
      X := T'First;
   end Ovrwrt_Stk;

begin
   A; Ovrwrt_Stk; A; Ovrwrt_Stk; A; Ovrwrt_Stk; A;
end Sttc;

$ ./sttc
 0
 1
 1
 1
$

Phew. Back to normal.

Re: Ada requires too much typing!

[Maciej Sobczak]

On 8 Cze, 10:53, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

> > In other words, you have been exposed to the overly object-oriented
> > style.
>
> And how is that any better then the over templatized way used today?

You mean - how is that any worse. :-)

The overly object-oriented style (OOO (tm)) promotes or even relies on
overly dynamic memory management model.
This naturally leads to Pointers Everywhere Driven Development (PEDD).

The overly templatized way has its disadvantages, but at least allows
to preserve the value-oriented design approach, which is simply safer.
With a reasonable use of typedefs (type renamings) I find it very
appropriate and readable.

> > As I've already said - this design approach is representative for
> > '80s. There is a reason for why today's most acknowledged libraries
> > are not designed this way.
>
> Yes, but it's speed over everything again.

No. I perceive it as safety over everything.

(yes, I'm intentionally provocative here, but there is a point,
really)

> This is why the why the STL  
> “classes” have no virtual destructor.

No. The STL classes have no virtual destructors, because they also
have no virtual functions and as such it makes absolutely no sense to
derive from them.

In other words, they are not intended for polymorphic use.

For comparison, think about IOStreams - this *is* a polymorphic
framework with lots of virtual functions. Take it as a proof that
design decisions in C++ are not "speed over everything". Polymorphism
just makes sense for IOStreams and it just does not for containers. Or
at least this is what C++ thought.

> vector<> had to be as fast as the  
> build in array.

Not really - it uses the dynamic memory, while built-in arrays do not
have to.

> Any  
> design compromise acceptable as long as speed is not compromised.

See IOStreams for contradiction of your claims.

> I don't like the STL much.

The designers of Ada.Containers did. ;-)

> The reason is that foremost I see myself as an  
> OO programmer and the language is just a tool.

I see myself as a software engineer and the paradigm is just a tool.

(again intentionally provocative here)

> Reading the rest of you post I wonder if C++ has given up on being an  
> object orientated language?

It has not given up anything, as the OO was never the focus. C++ is a
multi-paradigm language, like Ada. It supports OO but does not force
it.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 9 Jun 2010 00:50:17 -0700 (PDT), Maciej Sobczak wrote:

> No. The STL classes have no virtual destructors, because they also
> have no virtual functions and as such it makes absolutely no sense to
> derive from them.
> 
> In other words, they are not intended for polymorphic use.

No, they are for parametrically polymorphic use.

Templates -> parametric (static) polymorphism
Virtual functions -> dynamic polymorphism
[ Overloading -> ad-hoc (static) polymorphism ]
 
> Polymorphism
> just makes sense for IOStreams and it just does not for containers.

Polymorphism is the essence of generic programming = programming in terms
of sets of types. That is what STL is all about, per fact and per intent
too (see Stepanov's interview).

>> Reading the rest of you post I wonder if C++ has given up on being an �
>> object orientated language?
> 
> It has not given up anything, as the OO was never the focus. C++ is a
> multi-paradigm language, like Ada. It supports OO but does not force
> it.

I am tempted to re-phrase a saying that multiple opinions on the same issue
(paradigms?) manifests freedom when in a society and schizophrenia when in
someone's head (language?).

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

Re: Ada requires too much typing!

[Maciej Sobczak]

On 9 Cze, 10:10, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > In other words, they are not intended for polymorphic use.
>
> No, they are for parametrically polymorphic use.

By "polymorphism" I meant the parametrisation based on dynamic
dispatch, also known as object-orientation.
Note, for example, that containers in C++ have no common base class/
interface. In Ada this is similar.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 9 Jun 2010 01:43:56 -0700 (PDT), Maciej Sobczak wrote:

> On 9 Cze, 10:10, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> In other words, they are not intended for polymorphic use.
>>
>> No, they are for parametrically polymorphic use.
> 
> By "polymorphism" I meant the parametrisation based on dynamic
> dispatch,

This is a specific form of polymorphism.

> also known as object-orientation.

There are different opinions on whether OO is limited to dynamic
polymorphism.

> Note, for example, that containers in C++ have no common base class/
> interface. In Ada this is similar.

There is a common base, which is just not explicit. This is one of the
weaknesses of parametric polymorphism that it does not provide any
substitute for the class (= set of types) embedded in the language. E.g.
you cannot name "all instances of a generic thing."

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

Re: Ada requires too much typing!

[Maciej Sobczak]

On 9 Cze, 11:24, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > By "polymorphism" I meant the parametrisation based on dynamic
> > dispatch,
>
> This is a specific form of polymorphism.

Yes, of course, there is also overloading as so-called "ad-hoc
polymorphism", etc.
I'm perfectly convinced that *everybody* understood what I meant in
this particular context, especially when the context itself contained
many references to virtual functions and object-orientation. What is
the purpose of your argument, then? Are we having a dispute just for
the sake of having it?

> > also known as object-orientation.
>
> There are different opinions on whether OO is limited to dynamic
> polymorphism.

In which case we will never finish debating.

> > Note, for example, that containers in C++ have no common base class/
> > interface. In Ada this is similar.
>
> There is a common base, which is just not explicit.

And you just forgot to explain what it is. Could you please elaborate
on this?
What is the common base class/interface for C++ or Ada containers? How
can I use it?

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 9 Jun 2010 06:54:18 -0700 (PDT), Maciej Sobczak wrote:

> On 9 Cze, 11:24, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Note, for example, that containers in C++ have no common base class/
>>> interface. In Ada this is similar.
>>
>> There is a common base, which is just not explicit.
> 
> And you just forgot to explain what it is. Could you please elaborate
> on this?
> What is the common base class/interface for C++ or Ada containers?

generic
   type Element is private;
package Generic_Stack is
   type Stack is limited private;
   ...
end Generic_Stack;

The common base is the [generic] interface of Stack, which all instances
share, which every programmer has in mind talking about stack.

> How can I use it?

You cannot, which is the problem of generics.

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

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 09 Jun 2010 11:24:16 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> There are different opinions on whether OO is limited to dynamic
> polymorphism.
So what else ? You meant static polymorphism ?

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Georg Bauhaus]

On 09.06.10 16:29, Dmitry A. Kazakov wrote:

> The common base is the [generic] interface of Stack, which all instances
> share, which every programmer has in mind talking about stack.
> 
>> How can I use it?
> 
> You cannot, which is the problem of generics.

Maybe with the exception of generic formal packages?
(With other problems popping up elsewhere.)

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 09 Jun 2010 17:02:03 +0200, Georg Bauhaus wrote:

> On 09.06.10 16:29, Dmitry A. Kazakov wrote:
> 
>> The common base is the [generic] interface of Stack, which all instances
>> share, which every programmer has in mind talking about stack.
>> 
>>> How can I use it?
>> 
>> You cannot, which is the problem of generics.
> 
> Maybe with the exception of generic formal packages?
> (With other problems popping up elsewhere.)

Close, but it is about compilation units, the abstraction of the contents
remains outside the language.

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

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 09 Jun 2010 16:31:24 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Wed, 09 Jun 2010 11:24:16 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> There are different opinions on whether OO is limited to dynamic
>> polymorphism.
> So what else ? You meant static polymorphism ?

It is usually pointed out that an OO program can be written in Assembler.
Then there is OO analysis and modeling.

I, personally, prefer to talk about ADTs and generic programming (in wide
sense), leaving OO to zealots.

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

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 09 Jun 2010 17:57:58 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> It is usually pointed out that an OO program can be written in Assembler.
> Then there is OO analysis and modeling.
>
> I, personally, prefer to talk about ADTs and generic programming (in wide
> sense), leaving OO to zealots.
OO is a modal (and there may be multiple modal providing abilities to  
express a given architecture)


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 09 Jun 2010 17:53:44 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> Maybe with the exception of generic formal packages?
>> (With other problems popping up elsewhere.)
>
> Close, but it is about compilation units, the abstraction of the contents
> remains outside the language.
So this should not be a compilation unit and this should be expressed in  
the language. Do you think about something at the level of types ? I guess  
this should be able to express a kind of structure, so: Canvas ? Patterns ?


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 09 Jun 2010 20:00:07 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Wed, 09 Jun 2010 17:53:44 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> Maybe with the exception of generic formal packages?
>>> (With other problems popping up elsewhere.)
>>
>> Close, but it is about compilation units, the abstraction of the contents
>> remains outside the language.
> So this should not be a compilation unit and this should be expressed in  
> the language. Do you think about something at the level of types ?

Depends on the intentions. If you render it as a type, then it must be a
class-wide one. This is the reason why I believe that generics are
superfluous and could be gradually replaced by classes. This is also why I
want more static analysis, because that would allow to remove any overhead
in comparable [=static] cases.

> I guess  
> this should be able to express a kind of structure, so: Canvas ? Patterns ?

Depends on the meaning of these. Normally this stuff comes with dynamic
typing, types inference, things I don't like to see in a language like Ada.

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

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 09 Jun 2010 21:10:06 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> So this should not be a compilation unit and this should be expressed in
>> the language. Do you think about something at the level of types ?
>
> Depends on the intentions. If you render it as a type, then it must be a
> class-wide one. This is the reason why I believe that generics are
> superfluous and could be gradually replaced by classes.

What would become formal parameters, like type parameters ? Overloading  
functions returning type derived from that of the ancestor one ? OK. So,  
this will require an original bas type in the root definition which could  
be wide enough to reach actual capabilities of generics. An “ANY” type  
(like in QBasic) ? An abstract base type ? OK. So, now, we will need to be  
able to declare abstract base type, that is, abstract discrete types, etc.  
Is that what's in your mind ?


>> I guess
>> this should be able to express a kind of structure, so: Canvas ?  
>> Patterns ?
>
> [...] Normally this stuff comes with dynamic
> typing, types inference, things I don't like to see in a language like  
> Ada.

No, this is not required (while this oftenly the case, yes)


> Depends on the meaning of these.

Just means “pattern” ;) well... pie dish, cake tin, waffle iron, and so on  
(btw, none of these latter requires dynamic typing)


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Maciej Sobczak]

On 9 Cze, 16:29, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > What is the common base class/interface for C++ or Ada containers?
>
> generic
>    type Element is private;
> package Generic_Stack is
>    type Stack is limited private;
>    ...
> end Generic_Stack;
>
> The common base is the [generic] interface of Stack, which all instances
> share, which every programmer has in mind talking about stack.

Do you mean that every container supports push and pop operations
(actually Append, Last_Element, Delete_Last, etc.)?

> > How can I use it?
>
> You cannot, which is the problem of generics.

Or maybe not generics in general, but the specific approach to
generics that was chosen by Ada.
Remember, in C++ this is not a problem:

#include <vector>
#include <list>

template <class ContainerOfInts>
void appendThreeInts(ContainerOfInts & c)
{
    c.push_back(7);
    c.push_back(42);
    c.push_back(123);
}

int main()
{
    std::vector<int> vec;
    std::list<int> lst;

    appendThreeInts(vec);
    appendThreeInts(lst);
}

The appendThreeInts function uses the implicit common interface, even
though vector and list do not share anything explicitly.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Wed, 09 Jun 2010 23:22:53 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
> Or maybe not generics in general, but the specific approach to
> generics that was chosen by Ada.
> Remember, in C++ this is not a problem:
>
> #include <vector>
> #include <list>
>
> template <class ContainerOfInts>
> void appendThreeInts(ContainerOfInts & c)
> {
>     c.push_back(7);
>     c.push_back(42);
>     c.push_back(123);
> }
>
> int main()
> {
>     std::vector<int> vec;
>     std::list<int> lst;
>
>     appendThreeInts(vec);
>     appendThreeInts(lst);
> }
>
> The appendThreeInts function uses the implicit common interface, even
> though vector and list do not share anything explicitly.
>
> --
> Maciej Sobczak * http://www.inspirel.com
>
> YAMI4 - Messaging Solution for Distributed Systems
> http://www.inspirel.com/yami4

Although it would requires a different layout (actually, just more typing  
;) ), the same is possible with Ada : just use a formal subrpogram  
parameter for pubsh_back.

You would better use the notation:
    with My_Subprogram (...signature...) is <>;
or even (left oftenly, while still valid and meaningful)

    with My_Subprogram (...signature...) is null;
to get benefit from static polymorphism.

About this kind of generic formal parameter, please, see [ARM 2005 12.16  
(2.1/2)] and [ARM 2005 12.16 (10)] and [ARM 2005 12.16 (10.1/2)].

Static polymorphism is achieved when you use a consistent naming shame for  
similar subprograms in different areas or packages : ex. you define a  
Lists package with a Push procedure and a Stacks package with a Push  
procedure also (same name in both package).

All of these, providing I have really understood what you were requesting  
for.

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:c459b285-851b-4d6f-95fe-0c28b58ddf45@e5g2000yqn.googlegroups.com...
On 8 Cze, 10:53, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

>> > In other words, you have been exposed to the overly object-oriented
>> > style.
>>
>> And how is that any better then the over templatized way used today?
>
>You mean - how is that any worse. :-)
>
>The overly object-oriented style (OOO (tm)) promotes or even relies on
>overly dynamic memory management model.
>This naturally leads to Pointers Everywhere Driven Development (PEDD).

Maybe in C++, but in Ada, if you are defining OOP using pointers, you are 
doing something wrong. (Probably copying a crappy design from some other 
language.) There should be almost no visible access types (and I say almost 
only to allow the accessor magic of Ada 2012).

When this is done, even the use of objects of 'Class can be managed with 
Ada.Containers, and any needed dynamic allocation can be completely hidden 
from the program. (And it rarely is needed in the first place.)

                                 Randy.

Re: Ada requires too much typing!

[AdaMagica]

On 10 Jun., 08:13, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> >The overly object-oriented style (OOO (tm)) promotes or even relies on
> >overly dynamic memory management model.
> >This naturally leads to Pointers Everywhere Driven Development (PEDD).
>
> Maybe in C++, but in Ada, if you are defining OOP using pointers, you are
> doing something wrong. (Probably copying a crappy design from some other
> language.) There should be almost no visible access types (and I say almost
> only to allow the accessor magic of Ada 2012).
>
> When this is done, even the use of objects of 'Class can be managed with
> Ada.Containers, and any needed dynamic allocation can be completely hidden
> from the program. (And it rarely is needed in the first place.)
>
>                                  Randy.

Randy, which AI is the favoured solution (there are several
proposals)? The current Amendment 2 RM is still Draft 8 which does not
include this accessor magic.

Re: Ada requires too much typing!

[Vadim Godunko]

On Jun 10, 10:13 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> Maybe in C++, but in Ada, if you are defining OOP using pointers, you are
> doing something wrong. (Probably copying a crappy design from some other
> language.) There should be almost no visible access types (and I say almost
> only to allow the accessor magic of Ada 2012).
>
I want to known more about how to use OOP in Ada without access types!

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Thu, 10 Jun 2010 08:34:07 +0200, Vadim Godunko <vgodunko@gmail.com> a  
écrit:
> I want to known more about how to use OOP in Ada without access types!
Wadim, if saying OOP, you meant dynamic dispatching, then you are indeed  
not required to use access type for that. Just use class-wide type : an  
object whose view is class-wide type, is dispatching. Alternatively and if  
needed, you can use a view conversion : if an object is not declared so  
that it has a class-wide type view, then you are still allowed to use a  
view-conversion expression.

Feel free to ask for, if you need more details or references to the ARM to  
read it your-self.

Have a nice day

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[AdaMagica]

On 10 Jun., 08:34, Vadim Godunko <vgodu...@gmail.com> wrote:
> I want to known more about how to use OOP in Ada without access types!

type Element is tagged ...
subtype Any_Element is Element'Class;

procedure Show (E: Element);

A: Element;
X: Any_Element := Initial_Value;

Show (A);            -- no dispatch
Show (X);            -- dispatches
Show (Element (X));  -- no dispatch

type Special_Element is new Element with ...;

procedure Handle (S: Special_Element) is
begin
  Show (S);                -- no dispatch
  Show (Any_Element (S));  -- re-dispatch
end Handle;

Re: Ada requires too much typing!

[Maciej Sobczak]

On 10 Cze, 08:13, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> >The overly object-oriented style (OOO (tm)) promotes or even relies on
> >overly dynamic memory management model.
> >This naturally leads to Pointers Everywhere Driven Development (PEDD).
>
> Maybe in C++

This is what Martin asked for.
It is possible to go pretty far without using pointers, but it's
enough to introduce at least one factory design pattern and you're
tied.
(but there is more, see below)

The Ada's ability to return unconstrained types from functions is
really good (it allows to initialize class-wide object based on run-
time decisions) and contributes to better handling of OO. This is a
very important difference and I found it illuminating when comparing
OO models in these two languages.

> (Probably copying a crappy design from some other
> language.) There should be almost no visible access types

Well, not so fast. Access types are necessary for referring to
existing objects.
Think about request handlers in AWS, for example - the idea is that
objects are *registered* somewhere for future use. How would you do
that without access types? At least obtaining the 'Access value is
necessary, even if the explicit use of access variables can be
avoided.

A similar idiom is used in YAMI4, where message handlers are instances
of types that derive from common interface:

http://www.inspirel.com/yami4/book/6-2-1.html

I am not aware of any way to support this functionality without access
types.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Vadim Godunko]

On Jun 10, 10:54 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Thu, 10 Jun 2010 08:34:07 +0200, Vadim Godunko <vgodu...@gmail.com> a  
> écrit:> I want to known more about how to use OOP in Ada without access types!
>
> Wadim, if saying OOP, you meant dynamic dispatching, then you are indeed  
> not required to use access type for that.
No, I more asked for real example where Ada's OOP is be used without
access types in OOP way. The only known example is Tuker's work on
some part of ASIS 05, but from my point of view this work is set of
tricks and assumptions successful for concrete example but not for
general use.

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 09 Jun 2010 23:09:52 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 09 Jun 2010 21:10:06 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>>> So this should not be a compilation unit and this should be expressed in
>>> the language. Do you think about something at the level of types ?
>>
>> Depends on the intentions. If you render it as a type, then it must be a
>> class-wide one. This is the reason why I believe that generics are
>> superfluous and could be gradually replaced by classes.
> 
> What would become formal parameters, like type parameters ?

Base types, class-wide types.

> Overloading  
> functions returning type derived from that of the ancestor one ? OK. So,  
> this will require an original bas type in the root definition which could  
> be wide enough to reach actual capabilities of generics. An “ANY” type  
> (like in QBasic) ?

Nope. The element of a stack is not just any type. It is a copyable type
(the class "private" in terms of Ada generics).

> An abstract base type ? OK. So, now, we will need to be  
> able to declare abstract base type, that is, abstract discrete types, etc.  
> Is that what's in your mind ?

Yes. These are abstract interfaces to be defined. This is an easy part BTW.

>> Depends on the meaning of these.
> 
> Just means “pattern” ;) well... pie dish, cake tin, waffle iron, and so on  
> (btw, none of these latter requires dynamic typing)

Pattern = design pattern, e.g. "Bridge pattern"?
Pattern = formal language description, e.g. *.adb?
Pattern = dynamic type specification to match?
   ...
and 100+ types of patterns known in AI and *PATTERN* recognition. (:-))

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

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Wed, 9 Jun 2010 14:22:53 -0700 (PDT), Maciej Sobczak wrote:

> On 9 Cze, 16:29, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> What is the common base class/interface for C++ or Ada containers?
>>
>> generic
>> � �type Element is private;
>> package Generic_Stack is
>> � �type Stack is limited private;
>> � �...
>> end Generic_Stack;
>>
>> The common base is the [generic] interface of Stack, which all instances
>> share, which every programmer has in mind talking about stack.
> 
> Do you mean that every container supports push and pop operations
> (actually Append, Last_Element, Delete_Last, etc.)?

Yes.

>>> How can I use it?
>>
>> You cannot, which is the problem of generics.
> 
> Or maybe not generics in general, but the specific approach to
> generics that was chosen by Ada.
> Remember, in C++ this is not a problem:
> 
> #include <vector>
> #include <list>
> 
> template <class ContainerOfInts>
> void appendThreeInts(ContainerOfInts & c)
> {
>     c.push_back(7);
>     c.push_back(42);
>     c.push_back(123);
> }
> 
> int main()
> {
>     std::vector<int> vec;
>     std::list<int> lst;
> 
>     appendThreeInts(vec);
>     appendThreeInts(lst);
> }
> 
> The appendThreeInts function uses the implicit common interface, even
> though vector and list do not share anything explicitly.

You didn't use it. Nowhere in the program it was manifested. It appears
that the program "uses" this common interface. But this "use" is as virtual
as one by the hex code produced by the compiler. Similarly you could take
an int variable, put there 4 and claim that the variable is even, "per
use".  But it is not.

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

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Thu, 10 Jun 2010 00:36:36 -0700 (PDT), Vadim Godunko wrote:

> On Jun 10, 10:54�am, Yannick Duch�ne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
>> Le Thu, 10 Jun 2010 08:34:07 +0200, Vadim Godunko <vgodu...@gmail.com> a �
>> �crit:> I want to known more about how to use OOP in Ada without access types!
>>
>> Wadim, if saying OOP, you meant dynamic dispatching, then you are indeed �
>> not required to use access type for that.

> No, I more asked for real example where Ada's OOP is be used without
> access types in OOP way.

Hmm, I never use access to tagged types except for:

1. Garbage collection
2. Mutable function arguments
3. Rosen's trick

BTW, by "access types in OOP way", do you mean pointers, references or
heap-allocated objects?

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

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Thu, 10 Jun 2010 10:07:17 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> What would become formal parameters, like type parameters ?
>
> Base types, class-wide types.
>
>> Overloading
>> functions returning type derived from that of the ancestor one ? OK. So,
>> this will require an original bas type in the root definition which  
>> could
>> be wide enough to reach actual capabilities of generics. An “ANY” type
>> (like in QBasic) ?
>
> Nope. The element of a stack is not just any type. It is a copyable type
> (the class "private" in terms of Ada generics).
>
>> An abstract base type ? OK. So, now, we will need to be
>> able to declare abstract base type, that is, abstract discrete types,  
>> etc.
>> Is that what's in your mind ?
>
> Yes. These are abstract interfaces to be defined. This is an easy part  
> BTW.
What about “not every thing in the same bag” philosophy ? (many others  
failed in this trap) Moving generics to dynamic polymorphism... would be  
dynamic polymorphism where there was a kind of static polymorphism. And  
this is not the same from the point of view of program proof you like so  
much (me too, I like).

Is there some kind of meta-class in you idea of a new modal ? (generics  
can define new types and thus can initiate new class of types, you will  
meta-class to achieve the same).

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Thu, 10 Jun 2010 09:36:36 +0200, Vadim Godunko <vgodunko@gmail.com> a  
écrit:
> No, I more asked for real example where Ada's OOP is be used without
> access types in OOP way. The only known example is Tuker's work on
> some part of ASIS 05, but from my point of view this work is set of
> tricks and assumptions successful for concrete example but not for
> general use.
Depends on the reason you feel to need it. Propose a specification, we may  
talk about a modal. Do you need it for allocation ? Allocation is not  
specific to the OOP-big-bag, and dispatching does not implies memory  
allocation, you can use pools, etc, in Ada most of things are orthogonal  
you know, and using dynamic dispatching in Ada does not stick you with  
anything else which you may be afraid will come with.

If you have an example behavior in another language you've practiced on a  
case similar to the one you want to drive with Ada, then let us know (so  
we will be more likely to understand what you have in mind).

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Vadim Godunko]

On Jun 10, 12:21 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> Hmm, I never use access to tagged types except for:
>
By "access types" I mean access to classwide types.

> BTW, by "access types in OOP way", do you mean pointers, references or
> heap-allocated objects?
>
I mean distinguishing of objects by instance in opposite to
distinguishing by value.

Re: Ada requires too much typing!

[Vadim Godunko]

On Jun 10, 11:20 am, AdaMagica <christoph.gr...@eurocopter.com> wrote:
> On 10 Jun., 08:34, Vadim Godunko <vgodu...@gmail.com> wrote:
>
> > I want to known more about how to use OOP in Ada without access types!
>
> type Element is tagged ...
> subtype Any_Element is Element'Class;
>
> procedure Show (E: Element);
>
Thank you for example, this is example of dispatching but not use of
Ada in heavy OOP style of programming. :-)

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Thu, 10 Jun 2010 10:44:02 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Thu, 10 Jun 2010 10:07:17 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:

>> Yes. These are abstract interfaces to be defined. This is an easy part  
>> BTW.
> What about “not every thing in the same bag” philosophy ? (many others  
> failed in this trap)

Who? The examples you probably have in mind use implementation inheritance,
which is obviously doomed to fail. In order to work, it must be interface
inheritance + ad-hoc supertypes (you cannot and need not declare everything
in advance).

> Moving generics to dynamic polymorphism... would be  
> dynamic polymorphism where there was a kind of static polymorphism. And  
> this is not the same from the point of view of program proof you like so  
> much (me too, I like).

It is exactly same, because programs themselves are even more dynamic than
types relationships. Nevertheless there is SPARK to deal with that.

The type system must be designed to help the compiler to do more static
analysis, provided that the programmer would be asked to give more
annotations to the types. (It cannot be more typing than we already have
with generics, with no safety whatsoever!)

> Is there some kind of meta-class in you idea of a new modal ? (generics  
> can define new types and thus can initiate new class of types, you will  
> meta-class to achieve the same).

I call this type algebra. There are operations that yield types from types
and values. Generic instantiation is such an operation. Derivation is
another. Array declaration is third. Type constraining is forth, etc.

If I were ARG, I would consider the algebraic type operations the language
needs, with the goals:

0. SIMPLIFY THE LANGUAGE
1. Reduce generics use no absolute minimum (without performance penalty)
2. Most of currently built-in types must become library-defined
3. The standard container library must be freed of generics
4. The problem of container subtypes to be solved (e.g. when and how a
container of subtypes becomes a subtype or not)
5. The problem of containers of class-wides to be solved (+ relation of a
container of class-wides to a container of specific types, when, how)

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

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Thu, 10 Jun 2010 01:51:54 -0700 (PDT), Vadim Godunko wrote:

> On Jun 10, 12:21�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>> Hmm, I never use access to tagged types except for:
>>
> By "access types" I mean access to classwide types.

I use them even less frequently than access to specific types. You probably
have in mind containers of class-wide objects? But they are really rare and
there is no need to leak access types into their interfaces. (Of course
excluding things like doubly-linked lists, graphs etc)

>> BTW, by "access types in OOP way", do you mean pointers, references or
>> heap-allocated objects?
>>
> I mean distinguishing of objects by instance in opposite to
> distinguishing by value.

By instance = by specific type? This is dispatch, need not to go through an
access type. Ada nicely allows me to hide access types behind
implementations. It is a pity that return by reference was scrapped in
favor of Pickwickian functions. Otherwise, even handles to objects might
have avoided access types.

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

Re: Ada requires too much typing!

[Georg Bauhaus]

On 10.06.10 11:07, Dmitry A. Kazakov wrote:

> I call this type algebra. There are operations that yield types from types
> and values. Generic instantiation is such an operation. Derivation is
> another. Array declaration is third. Type constraining is forth, etc.
> 
> If I were ARG, I would consider the algebraic type operations the language
> needs, with the goals:
> 
> 0. SIMPLIFY THE LANGUAGE
> 1. Reduce generics use no absolute minimum (without performance penalty)
> 2. Most of currently built-in types must become library-defined
> 3. The standard container library must be freed of generics
> 4. The problem of container subtypes to be solved (e.g. when and how a
> container of subtypes becomes a subtype or not)
> 5. The problem of containers of class-wides to be solved (+ relation of a
> container of class-wides to a container of specific types, when, how)

What will be the type of a non-generic package?

Re: Ada requires too much typing!

[Georg Bauhaus]

On 10.06.10 10:57, Vadim Godunko wrote:
> On Jun 10, 11:20 am, AdaMagica <christoph.gr...@eurocopter.com> wrote:
>> On 10 Jun., 08:34, Vadim Godunko <vgodu...@gmail.com> wrote:
>>
>>> I want to known more about how to use OOP in Ada without access types!
>>
>> type Element is tagged ...
>> subtype Any_Element is Element'Class;
>>
>> procedure Show (E: Element);
>>
> Thank you for example, this is example of dispatching but not use of
> Ada in heavy OOP style of programming. :-)

Will it, in theory, be possible to write a Qt-like library
in Ada such that client programs declare variables like

   W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);

That is, programs do not use access Some_Window'Class?

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Thu, 10 Jun 2010 12:10:02 +0200, Georg Bauhaus wrote:

> On 10.06.10 11:07, Dmitry A. Kazakov wrote:
> 
>> I call this type algebra. There are operations that yield types from types
>> and values. Generic instantiation is such an operation. Derivation is
>> another. Array declaration is third. Type constraining is forth, etc.
>> 
>> If I were ARG, I would consider the algebraic type operations the language
>> needs, with the goals:
>> 
>> 0. SIMPLIFY THE LANGUAGE
>> 1. Reduce generics use no absolute minimum (without performance penalty)
>> 2. Most of currently built-in types must become library-defined
>> 3. The standard container library must be freed of generics
>> 4. The problem of container subtypes to be solved (e.g. when and how a
>> container of subtypes becomes a subtype or not)
>> 5. The problem of containers of class-wides to be solved (+ relation of a
>> container of class-wides to a container of specific types, when, how)
> 
> What will be the type of a non-generic package?

Packages have no types.

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

Re: Ada requires too much typing!

[Maciej Sobczak]

On 10 Cze, 10:15, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > The appendThreeInts function uses the implicit common interface, even
> > though vector and list do not share anything explicitly.
>
> You didn't use it.

I used it in the same way as I can use (for example) the addition
operator for integer literals.

> Nowhere in the program it was manifested.

Just as the addition operator for integer literals?

The fact that something has no declared name in the program does not
mean that it doesn't exist.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Ada requires too much typing!

[Alex R. Mosteo]

Georg Bauhaus wrote:

> On 10.06.10 10:57, Vadim Godunko wrote:
>> On Jun 10, 11:20 am, AdaMagica <christoph.gr...@eurocopter.com> wrote:
>>> On 10 Jun., 08:34, Vadim Godunko <vgodu...@gmail.com> wrote:
>>>
>>>> I want to known more about how to use OOP in Ada without access types!
>>>
>>> type Element is tagged ...
>>> subtype Any_Element is Element'Class;
>>>
>>> procedure Show (E: Element);
>>>
>> Thank you for example, this is example of dispatching but not use of
>> Ada in heavy OOP style of programming. :-)
> 
> Will it, in theory, be possible to write a Qt-like library
> in Ada such that client programs declare variables like
> 
>    W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
> 
> That is, programs do not use access Some_Window'Class?

Interesting question, because e.g. in GtkAda I found the use of renamed 
access types most confusing at first.

I guess Vadim is the man to answer about Qt + Ada :)

Re: Ada requires too much typing!

[Alex R. Mosteo]

Martin Krischik wrote:

(...)

> 
> function f returns Integer
> 
>    package i is
>      g : Integer := 0;
>    end i;
> 
> begin
>    i.g := i.g + 1;
>    return i.g;
> end f;

Do you mean that i.g retains value across calls here? Never saw this 
construct before, and not what I would have thought... interesting.

Re: Ada requires too much typing!

[Dmitry A. Kazakov]

On Thu, 10 Jun 2010 06:37:28 -0700 (PDT), Maciej Sobczak wrote:

> On 10 Cze, 10:15, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> The appendThreeInts function uses the implicit common interface, even
>>> though vector and list do not share anything explicitly.
>>
>> You didn't use it.
> 
> I used it in the same way as I can use (for example) the addition
> operator for integer literals.

(Integer literals have one type Universal_Integer)

More generally the type "abstract integer" exists, but cannot be properly
used in Ada. In generics it is referenced as "range <>". This is a design
flaw and the same problem.

> The fact that something has no declared name in the program does not
> mean that it doesn't exist.

It means that it does not exist in the program. It may exist in the
programmer's head, one the paper etc, but that is irrelevant to the
language.

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

Re: Ada requires too much typing!

[Alex R. Mosteo]

Georg Bauhaus wrote:

> On 08.06.10 12:10, Niklas Holsti wrote:
>> Martin Krischik wrote:
>> 
>>> just about as painful as using local packages to add static variables
>>> to Ada procedures.
>> 
>> Later Martin Krischik wrote:
>> 
>>> function f returns Integer
>>>
>>>   package i is
>>>     g : Integer := 0;
>>>   end i;
>>>
>>> begin
>>>   i.g := i.g + 1;
>>>   return i.g;
>>> end f;
>> 
>> If you mean the latter code to be an example of the former task (add
>> static variable), I believe you are mistaken.
> 
> I thought, too, that a new variable decl inside the local package
> would still be elaborated each time. The initilization of g
> confirms when tested.
> 
> But then I thought, surprise!, doubted everything I thought
> I had learned about Ada. Looking at this:
> 
> with Ada.Text_IO;  use Ada.Text_IO;
> 
> procedure Sttc is
> 
>    type T is range 0 .. 10;
> 
>    procedure A is
>       package P is  -- local package
>          V: T;    -- presumably static?
>       end P;
>    begin
>       if P.V'Valid then
>          P.V := P.V + 1;
>       else
>          P.V := T'First;
>       end if;
>       Put_Line (T'Image(P.V));
>    end A;
> 
> begin
>    A; A; A;
> end Sttc;
> 
> 
> $ ./sttc
>  0
>  1
>  2
>  3
> $
> 
> Compiled with or without -gnatVa.  But this seems to be accidental,
> V is just a variable that isn't initialized, living on the stack.
> Confirmation:
> 
> with Ada.Text_IO;  use Ada.Text_IO;
> 
> procedure Sttc is
> 
>    type T is range 0 .. 10;
> 
>    procedure A is
>       package P is
>          V: T;
>       end P;
>    begin
>       if P.V'Valid then
>          P.V := P.V + 1;
>       else
>          P.V := T'First;
>       end if;
>       Put_Line (T'Image(P.V));
>    end A;
> 
>    procedure Ovrwrt_Stk  is
>       X : T;
>    begin
>       X := T'First;
>    end Ovrwrt_Stk;
> 
> begin
>    A; Ovrwrt_Stk; A; Ovrwrt_Stk; A; Ovrwrt_Stk; A;
> end Sttc;
> 
> $ ./sttc
>  0
>  1
>  1
>  1
> $
> 
> Phew. Back to normal.

Hehehe here too :)

Nice example BTW with the stack.

Re: Ada requires too much typing!

[J-P. Rosen]

Alex R. Mosteo a �crit :
> Martin Krischik wrote:
> 
> (...)
> 
>> function f returns Integer
>>
>>    package i is
>>      g : Integer := 0;
>>    end i;
>>
>> begin
>>    i.g := i.g + 1;
>>    return i.g;
>> end f;
> 
> Do you mean that i.g retains value across calls here? Never saw this 
> construct before, and not what I would have thought... interesting.
No! In Ada, no construct lives longer than its scope (unlike C static
variables)

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada requires too much typing!

[Yannick Duchêne (Hibou57)]

Le Tue, 08 Jun 2010 12:10:38 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> To make a statically allocated variable, you need a library package.  
> Perhaps you are thinking of the technique suggested by Mark Lundquist,  
> at http://www.adapower.com/index.php?Command=Class&ClassID=Basics&CID=204
>
> That technique uses a nested package inside a library package, but not  
> within the subprogram using the variable. The nesting is used only to  
> hide the variable from other subprograms that are in the same library  
> package but are not in the nested package.
The general technique is a construct where a package (the one holding the  
variable) is elaborated only once.


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Ada requires too much typing!

[Vadim Godunko]

On Jun 10, 2:12 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
>
> Will it, in theory, be possible to write a Qt-like library
> in Ada such that client programs declare variables like
>
>    W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
>
> That is, programs do not use access Some_Window'Class?

Unfortunately, not now. All you can use now is instantiation of
Qt_Ada.Generic_Object_Pointers as "container" for your object. This
package is instantiated for every subclass derived from QObject. This
generic introduces interesting idea of managing referenced object's
life cycle, stored reference is automatically resetted to null when
object is destroyed. By the way, ARG can think about such
functionality in the next standard of the language, for example by
returning back reference semantic for limited tagged types and their
classwide companions. I think that this capability can significantly
improve usage of the language outside of embedded system sector. And
as gigantic example to test new language capabilities ARG can use...
UML metamodel, it contains most kinds (and may be even all) of complex
relations between classes.

Re: Ada requires too much typing!

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Well, not so fast. Access types are necessary for referring to
> existing objects.

And for passing around limited objects; the example I have in mind is
events in an event-driven system. Some description
.. http://coldframe.sourceforge.net/coldframe/event-use.html#postinganevent

Re: Ada requires too much typing!

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> with Ada.Text_IO;  use Ada.Text_IO;
>
> procedure Sttc is
>
>    type T is range 0 .. 10;
>
>    procedure A is
>       package P is
>          V: T;
         pragma Export (C, V, "naughty_v");      --<<<<<<<<<<
>       end P;
>    begin
>       if P.V'Valid then
>          P.V := P.V + 1;
>       else
>          P.V := T'First;
>       end if;
>       Put_Line (T'Image(P.V));
>    end A;
>
>    procedure Ovrwrt_Stk  is
>       X : T;
>    begin
>       X := T'First;
>    end Ovrwrt_Stk;
>
> begin
>    A; Ovrwrt_Stk; A; Ovrwrt_Stk; A; Ovrwrt_Stk; A;
> end Sttc;
>
> $ ./sttc
>  0
>  1
>  1
>  1
> $
>
> Phew. Back to normal.

$ gnatmake sttc -f -gnatVa
gcc -c -gnatVa sttc.adb
sttc.adb:10:28: warning: "V" has been made static as a result of Export
sttc.adb:10:28: warning: this usage is non-standard and non-portable
gnatbind -x sttc.ali
gnatlink sttc.ali
$ ./sttc
 1
 2
 3
 4

(this is a GNAT-ism, of course, and is present in at least GNAT Pro
3.16a1 for powerpc-wrs-vxworks and GCC 4.5.0 for x86_64-apple-darwin10).

Re: Ada requires too much typing!

[Niklas Holsti]

Simon Wright wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> with Ada.Text_IO;  use Ada.Text_IO;
>>
>> procedure Sttc is
>>
>>    type T is range 0 .. 10;
>>
>>    procedure A is
>>       package P is
>>          V: T;
>          pragma Export (C, V, "naughty_v");      --<<<<<<<<<<
>>       end P;
>>    begin
>>       if P.V'Valid then
>>          P.V := P.V + 1;
>>       else
>>          P.V := T'First;
>>       end if;
>>       Put_Line (T'Image(P.V));
>>    end A;
>>
>>    procedure Ovrwrt_Stk  is
>>       X : T;
>>    begin
>>       X := T'First;
>>    end Ovrwrt_Stk;
>>
>> begin
>>    A; Ovrwrt_Stk; A; Ovrwrt_Stk; A; Ovrwrt_Stk; A;
>> end Sttc;
>>
>> $ ./sttc
>>  0
>>  1
>>  1
>>  1
>> $
>>
>> Phew. Back to normal.
> 
> $ gnatmake sttc -f -gnatVa
> gcc -c -gnatVa sttc.adb
> sttc.adb:10:28: warning: "V" has been made static as a result of Export
> sttc.adb:10:28: warning: this usage is non-standard and non-portable
> gnatbind -x sttc.ali
> gnatlink sttc.ali
> $ ./sttc
>  1
>  2
>  3
>  4
> 
> (this is a GNAT-ism, of course, and is present in at least GNAT Pro
> 3.16a1 for powerpc-wrs-vxworks and GCC 4.5.0 for x86_64-apple-darwin10).

It is also present in GNAT 4.3 in debian lenny.

You can even initialize V in its declaration, for example as V : T : = 
T'First, and GNAT will make this initialization happen once. No need for 
the unreliable trickery with 'Valid.

Interesting curio to know, but as for using it... nah.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada requires too much typing!

[Randy Brukardt]

"AdaMagica" <christoph.grein@eurocopter.com> wrote in message 
news:4db36585-569d-4f24-ab95-0c7177e5d09b@d8g2000yqf.googlegroups.com...
On 10 Jun., 08:13, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> When this is done, even the use of objects of 'Class can be managed with
>> Ada.Containers, and any needed dynamic allocation can be completely 
>> hidden
>> from the program. (And it rarely is needed in the first place.)
>
>Randy, which AI is the favoured solution (there are several
>proposals)? The current Amendment 2 RM is still Draft 8 which does not
>include this accessor magic.

Right. AI05-0139-2 contains the syntax, AI05-0142-4 contains a related 
feature, and AI05-0212-1 contains the changes needed to the predefined 
containers for the first two.

I'd wait to read those until next week; Tucker is supposed to be providing 
major updates to AI05-0139-2 and AI05-0142-4 by tomorrow afternoon and I'll 
be posting them over the weekend before leaving for Vallencia. (AI05-0212-1 
is mostly empty still, waiting for the other two to get much closer to 
completion. We had problems deciding on names of things in the past (even 
though no one use those names, we still have to have them), but otherwise 
the basic structure is already known).

Also in the next few days, the next AARM draft will be posted.

                               Randy.

Re: Ada requires too much typing!

[Randy Brukardt]

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

"Vadim Godunko" <vgodunko@gmail.com> wrote in message 
news:35dd1a8f-1af8-4979-9663-29f7f4cb302e@g19g2000yqc.googlegroups.com...
On Jun 10, 10:54 am, Yannick Duch�ne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
>> Le Thu, 10 Jun 2010 08:34:07 +0200, Vadim Godunko <vgodu...@gmail.com> a
>> �crit:> I want to known more about how to use OOP in Ada without access 
>> types!
>>
>> Wadim, if saying OOP, you meant dynamic dispatching, then you are indeed
>> not required to use access type for that.
>No, I more asked for real example where Ada's OOP is be used without
>access types in OOP way. The only known example is Tuker's work on
>some part of ASIS 05, but from my point of view this work is set of
>tricks and assumptions successful for concrete example but not for
>general use.

Claw only uses a handful of access types in its interfaces (internally is a 
different story, but irrelevant to this discussion). Most Claw example 
programs use no access types at all.

> By "access types" I mean access to classwide types.

If you need to do this, using an indefinite container to hold the objects is 
preferable to using explicit access types. Again, access types probably are 
used to implement the container, but they aren't visible anywhere. This 
eliminates the horrors of explicit storage management and most (or all, 
depending on the implementation) of the unsafeness of access types without 
any distributed overhead. (Unlike garbage collection, which has to be done 
on all objects to work, so even objects that don't need management have to 
pay for it.)

                                 Randy.

Re: Ada requires too much typing!

[Gautier write-only]

On Jun 10, 12:12 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:

> Will it, in theory, be possible to write a Qt-like library
> in Ada such that client programs declare variables like
>
>    W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
>
> That is, programs do not use access Some_Window'Class?

In theory, I don't know, but in practice it is possible ;-).
Look at GWindows for instance.
And I'm sure (hum, why am I so sure ?...) that CLAW as well is a GUI
library without need of accesses.
At least on GWindows the only need I've seen, up to now, for accesses
is when it comes to create an undetermined number of MDI windows (e.g.
in the TeXCAD app).
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm

Re: Ada requires too much typing!

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4c10baa2$0$6974$9b4e6d93@newsspool4.arcor-online.net...
> On 10.06.10 10:57, Vadim Godunko wrote:
>> On Jun 10, 11:20 am, AdaMagica <christoph.gr...@eurocopter.com> wrote:
>>> On 10 Jun., 08:34, Vadim Godunko <vgodu...@gmail.com> wrote:
>>>
>>>> I want to known more about how to use OOP in Ada without access types!
>>>
>>> type Element is tagged ...
>>> subtype Any_Element is Element'Class;
>>>
>>> procedure Show (E: Element);
>>>
>> Thank you for example, this is example of dispatching but not use of
>> Ada in heavy OOP style of programming. :-)
>
> Will it, in theory, be possible to write a Qt-like library
> in Ada such that client programs declare variables like
>
>   W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
>
> That is, programs do not use access Some_Window'Class?

We could have done this in Claw, but we found little need for "generic 
windows". At some point, you have to declare the specific window object that 
you need, and at that point you might as well just declare an object of that 
type.

Claw allows window objects to be assigned, so you could definitely do 
something like:

   declare
      My_Window : Claw.Basic_Window.Window;
   begin
      Global_Window := Root_Window_Type'Class(My_Window);
   end;

Unfortunately, Ada doesn't allow the changing of the tags of declared 
classwide objects. (This is a language bug in my view, but hardly anyone 
elses.) So you have to use an Ada 2012 holder container:

   declare
      My_Window : Claw.Basic_Window.Window;
   begin
      Global_Window.Replace_Element (Root_Window_Type'Class(My_Window));
   end;

where Global_Window is defined as:

    package Global_Holder is new Ada.Containers.Indefinite_Holder 
(Claw.Root_Window_Type'Class);

    Global_Window : Global_Holder;


                                 Randy.

Re: Ada requires too much typing!

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:fef531f2-0f35-4ba5-8e79-9ae59e2a6a25@x21g2000yqa.googlegroups.com...
> On 10 Cze, 08:13, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
...
>> (Probably copying a crappy design from some other
>> language.) There should be almost no visible access types
>
> Well, not so fast. Access types are necessary for referring to
> existing objects.
> Think about request handlers in AWS, for example - the idea is that
> objects are *registered* somewhere for future use. How would you do
> that without access types? At least obtaining the 'Access value is
> necessary, even if the explicit use of access variables can be
> avoided.

I'm talking about in the interfaces. Ada always allows you to take 'Access 
of tagged parameters, so the implementation of a class can surely do that if 
needed. But it should never, ever, expose that cruft to the clients.

This is exactly how Claw works: a mess of access type cruft under the 
covers, almost no access types in the interfaces. The only existing access 
types are used to return access to existing objects; that will remain in the 
Ada 2012 design but it will be safe (unlike in the Ada 95 Claw design) 
because the lifetime of the returned access will have to be shorter than the 
existing objects (absent Unchecked_Deallocation, the destroyer of all that 
is safe ;-), and you won't actually have to write any of the dereferencing 
(it will look syntactically like you are reading/modifying the object itself 
in place).

                                            Randy.

Re: Ada requires too much typing!

[Stephen Leake]

Vadim Godunko <vgodunko@gmail.com> writes:

> On Jun 10, 10:13 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> Maybe in C++, but in Ada, if you are defining OOP using pointers, you are
>> doing something wrong. (Probably copying a crappy design from some other
>> language.) There should be almost no visible access types (and I say almost
>> only to allow the accessor magic of Ada 2012).
>>
> I want to known more about how to use OOP in Ada without access types!

I have an example of using Ada.Containers instead of access types at
http://www.stephe-leake.org/ada/access_vs_object.html

Ada 2005 isn't really ready for this; Ada 2012 will come closer, but I
think Randy is overstating his case.

-- 
-- Stephe

Re: Ada requires too much typing!

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Claw only uses a handful of access types in its interfaces (internally is a 
> different story, but irrelevant to this discussion). 

No, it's not irrelevant, if we are talking about implementing libraries,
rather than using them!

-- 
-- Stephe

Re: Ada requires too much typing!

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> On 10.06.10 10:57, Vadim Godunko wrote:
>> On Jun 10, 11:20 am, AdaMagica <christoph.gr...@eurocopter.com> wrote:
>>> On 10 Jun., 08:34, Vadim Godunko <vgodu...@gmail.com> wrote:
>>>
>>>> I want to known more about how to use OOP in Ada without access types!
>>>
>>> type Element is tagged ...
>>> subtype Any_Element is Element'Class;
>>>
>>> procedure Show (E: Element);
>>>
>> Thank you for example, this is example of dispatching but not use of
>> Ada in heavy OOP style of programming. :-)
>
> Will it, in theory, be possible to write a Qt-like library
> in Ada such that client programs declare variables like
>
>    W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
>
> That is, programs do not use access Some_Window'Class?

No. Because the underlying C++ uses pointers, so the Ada has to as well.

-- 
-- Stephe

Re: Ada requires too much typing!

[Alex R. Mosteo]

J-P. Rosen wrote:

> Alex R. Mosteo a écrit :
>> Martin Krischik wrote:
>> 
>> (...)
>> 
>>> function f returns Integer
>>>
>>>    package i is
>>>      g : Integer := 0;
>>>    end i;
>>>
>>> begin
>>>    i.g := i.g + 1;
>>>    return i.g;
>>> end f;
>> 
>> Do you mean that i.g retains value across calls here? Never saw this
>> construct before, and not what I would have thought... interesting.
> No! In Ada, no construct lives longer than its scope (unlike C static
> variables)

Yep, I saw in other reply. I admit it was a most unsettling idea at first 
sight.

Re: Ada requires too much typing!

[Jeffrey R. Carter]

Stephen Leake wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> Will it, in theory, be possible to write a Qt-like library
>> in Ada such that client programs declare variables like
>>
>>    W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
>>
>> That is, programs do not use access Some_Window'Class?
> 
> No. Because the underlying C++ uses pointers, so the Ada has to as well.

In the implementation, sure. But the question was about the client; I suspect it 
would be possible to design the binding so the client need not use pointers.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Ada requires too much typing!

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>    declare
>       My_Window : Claw.Basic_Window.Window;
>    begin
>       Global_Window.Replace_Element (Root_Window_Type'Class(My_Window));
>    end;

So Claw.Basic_Window.Window isn't limited?

Not immediately clear what the semantics of copying a window are (absent
any knowledge of Claw!)

Re: Ada requires too much typing!

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2typ92z53.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>    declare
>>       My_Window : Claw.Basic_Window.Window;
>>    begin
>>       Global_Window.Replace_Element (Root_Window_Type'Class(My_Window));
>>    end;
>
> So Claw.Basic_Window.Window isn't limited?
>
> Not immediately clear what the semantics of copying a window are (absent
> any knowledge of Claw!)

Right, it's not limited. In Claw, a window object provides a view of a 
window; there can be multiple views (via assignment, function return, or the 
like). Operations on a view generally are applied to the window itself (such 
as being moved or closed). If the last view of a window is finalized, then 
the window itself is destroyed.

The advantage of non-limited windows should be fairly obvious: it's possible 
to pass a window as a parameter and save it somewhere. This is especially 
useful for passing windows to tasks at start-up (each task can have it's own 
window to write into).

None of this requires any explicit access types as the client level - Claw 
itself manages these as needed. And that means no explicit storage 
management is needed, either.

                                    Randy,