Hello.
OK, I think all things are going well. Since GPL v2 has some
paragraphs about copyright output and there going to
be version 3 that will (may) reflect this more close - all
questions are resolved.
Early next week we'll put link to sources on our web page
too.
Let me back to topic I've risen some months ago in
$classpath mal-list.
The question was about library support of call-by-contract
feature of the compiler/language.
I'm sure, you understand, that (standard) libraries are as valuable,
as the language itself. The practice shows, that usage or ignorance
of language constructions mostly fully depends on their
support in libraries. For example - call-by-contract.
Ideally, it's possible to guarantee that no NullPointerException,
ClassCastException or ArrayIndexOutOfBounds exceptions
will occur, if proper checks will be added to source
code, because it's relatively easy to check code flow
control to analyze possibility of assignment or usage of "null",
and so on. But lack of information of this kind, bound to
standard library methods, makes this kind of programming
rules very hard to follow, since you *must* check any
returned value against 'null'. And standard classes and their
methods are heavily used, so instead of programming you'll
become monkey to type those checks.
That's why I need a help from authors of libraries. As far as
most of methods will have constraints about 'null' arguments
and/or return values - the programmer will be able to
enforce NullPointerException check and become sure
of code validness with relatively small numbers of manual
checks for 'null' assignments.
ClassCastException and ArrayIndexOutOfBoundsException
also may be avoided. My own practice shows that these three
types of exceptions cover about 90% of run-time errors.
Enforcing check for these exceptions may dramatically
decrease number of errors. Sorry to say, but 2 of 3 non-trivial
applets I've tried on the net - crashed with one of those
exception :-(
And such kind of enforcements is impossible without library
support, since about every method in standard library should
have some kind of constraints.
As Peter Mehlitz wrote to me in on of letters - we can't just
follow Sun and simply redo their work, we need something
new. I fully agreed with him. Just reimplementing of Sun's
libraries may not be the ultimate task. There should be something
more that "more optimized version of core classes".
So, are you interested in such kind of cooperation?
PS Paul, have you tried to compile $classpath sources
with kiev? Any errors/warnings?
-----Original Message-----
From: Paul Fisher <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 23 ������� 1998 �. 22:20
Subject: Re: Free Java compiler - Kiev
>Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> So perhaps a reasonable course of action would be
>> to make the compiler display this information all the time
>> for the moment, and when GPL version 3 is available,
>> change to using an option to output this.
>
>Here's a relevant patch which will cause Section 2, Part C of the GPL
>to apply to The Kiev Compiler, thus making the extra clause
>unnecessary. Whenever any derived work is invoked interactively, the
>copyright line will be displayed.
>
>diff -ur old/kiev-0.08-src/kiev/Main.java kiev-0.08-src/kiev/Main.java
>--- old/kiev-0.08-src/kiev/Main.java Wed Oct 21 16:09:36 1998
>+++ kiev-0.08-src/kiev/Main.java Fri Oct 23 15:12:36 1998
>@@ -47,6 +47,7 @@
> public static OutputStream output;
>
> public static void main(String[] args) {
>+ System.out.println("Copyright (C) 1997, 1998 Forestro,
http://forestro.com");
> String addr = null;
> int port = 1966;
> for(int i=0; i < args.length; i++) {
>
>Once Version 3 of the GPL is released, you can move the println off to
>a command-line option.
>
>Does this seem OK?
