Forums

by Torrie Moore >> Fri, 11 Feb 2000 0:08:04 GMT

Other languages offer warnings during compilation. There is possibilities for some warnings to be build into the Jade compiler. For example comparing two objects of different types. I sure there are other cases where a warning would catch bugs before they happen. What do others think?

Torrie

by Eric Peachey >> Tue, 15 Feb 2000 1:46:34 GMT

Umm.. Not come across too many occasions where warnings might have been useful (unless the compiler writers somehow build in stuff for detecting that the programmer is trying to do something completely insane!)

Slightly related issue: what could also be useful would be the ability to define some kind of conditional compilation like you have in C. I'm particularly thinking of things like method preconditions, postconditions and class invariant mechanisms (a la Meyer) which you want to have enabled for development but not necessarily for production systems where such checks can impact performance (and any bugs trapped by the checks should have been caught during development). This is probably a bit of a bigger topic than compilation warnings though...

Eric in Edinbrrrrrr! of the South

by Robert Barr >> Tue, 15 Feb 2000 4:42:44 GMT

Umm.. Not come across too many occasions where warnings might have been useful (unless the compiler writers somehow build in stuff for detecting that the programmer is trying to do something completely insane!)

I think compiler warnings in JADE are mostly irrelevant. A
'higher-level' language protects the developer from the flexibility of c/c++, e.g. common pointer abuse like *(p+1) and other direct memory access problems don't apply. Neither do linker and other predeclaration type warnings. I haven't looked at a compiler warning list, so there may be some other specifics that would be useful. However, for the case of object comparison, (when casting from a superclass to a subclass?), I'd be pretty peeved if I couldn't permanently disable this warning.

Slightly related issue: what could also be useful would be the ability to define some kind of conditional compilation like you have in C. I'm particularly thinking of things like method preconditions, postconditions and class invariant mechanisms (a la Meyer) which you want to have enabled for development but not necessarily for production systems where such checks can impact performance (and any bugs trapped by the checks should have been caught during development). This is probably a bit of a bigger topic than compilation warnings though...

You have my vote on this one - this would improve the robustness of
reuse class implementations, and reduce the amount of condition checking code in routines.

I wonder if pre/post condition and invariant assertion failures be implemented as exceptions, and if so, what specific behaviour would be required?


<waffle>
This brings to mind another posting (in jade_tech_design_architecture)
on parameter overrides on the create method. A desire was expressed to enforce in the class definition (rather than relying upon a convention
of method call sequence) that the name property of the class Person was not null. Perhaps a mechanism using class invariant and an 'initialised' flag would acheive this? e.g.

class Person
invariant
(name <> null) or (not initialised)


The initialise method sets the flag. Every exported method (except
create and initialise) has the precondition:

method myMethod
require
initialised = true;begin

.....
end;


This appears at first sight to be at odds with Meyer's statement that "Create may be seen as the operation that ensures that all instances of
a class start their life in a correct mode". However the above implementation only serves to force the call sequence convention (as create and initialise are inseparable), so the intent of the statement is not violated.

(This example is not intended as an argument for providing such assertions in JADE - I'm sure there are far better cases!)
</waffle>

by Dean Cooper >> Tue, 15 Feb 2000 5:13:00 GMT

Asserts, pre-conditions and post-conditions are all good ideas. We've seen several systems in which users have implemented their own assert routines. One idea we've been kicking around on and off for a while is adding pre-condition and post-condition sections to methods. They could in fact be seen as part of the method's signature (ie: Meyer's "programming by contract"). For example:

someMethod();
preconditions
// boolean pre-condition expressions
postconditions
// boolean post-condition expressions

constants

vars
begin


epilog

end;

Precondition expressions would be evaluated on entry to a method; postcondition expressions on return. Any expression that returns false could raise an exception so that they could be caught by user exception handlers. Evaluation of pre-conditions and post-conditions in production systems could be controlled by the existing "production mode" flag (set/unset in Jade 5 using jdbutil.exe). If production mode is set, pre- and post-conditions are not evaluated.

Comments?

Dean.

by Carl Ranson >> Tue, 15 Feb 2000 20:31:00 GMT

Dean, its good that you've listed the conditions as part of the signature because is reinforces an idea that isn't immediately obvious. i.e. that the pre and post conditions apply to ALL reimplementations of the method.

e.g.
Stack.dequeue() : Object updating;
precondition
self.size > 0; // must be at least one item queued.
postcondition
self.size = old self.size -1; // and item must have been removed {body}

This is effectively a specification of the dequeue operation regardless of the implementation. It then becomes impossible to abuse the dequeue method by reimplementation. therefore all clients of the class can rely on the operation.

Carl

by Wilfred Verkley >> Mon, 21 Feb 2000 20:52:45 GMT

Asserts, pre-conditions and post-conditions are all good ideas. We've seen several systems in which users have implemented their own assert routines. One idea we've been kicking around on and off for a while is adding pre-condition and post-condition sections to methods. They could in fact be seen as part of the method's signature (ie: Meyer's "programming by contract"). For example:

One thing that slightly annoys me is that Jade does all this kind of stuff at the method level.

exception handling, epilogs, your proposed pre&post-conditions etc.

I know the reason for this is probably fairly fundamental in the JOM, but it would be nice if these sort of constructs could happen within the code

ie

foreach jadeUser in fAllMyJadeUsers
beginEpilog
doSomething;
epilog
doTheCleanup;
endEpilog
endforeach

or

foreach jadeUser in fAllMyJadeUsers
beginException
raiseLicencePrice;
handleException
apologizeToUser;
endException
endforeach


The purists are saying, "break it up into seperate methods", but sometimes its just much nicer if you can do it in one place.

Wilfred.

by Eric Peachey >> Mon, 21 Feb 2000 22:07:23 GMT

I know the reason for this is probably fairly fundamental in the JOM, but it would be nice if these sort of constructs could happen within the code

ie

foreach jadeUser in fAllMyJadeUsers
beginEpilog
doSomething;
epilog
doTheCleanup;
endEpilog
endforeach

Interesting point Wilfred. Forte does this kind of thing in its language (TOOL). From memory you'd have a block of code something like:
begin

blah();
blahBlah();
on exception
blahBlahBlah();
end;

(I suppose other languages have similar type structures using 'try' and 'catch' etc.?)

You could also nest the blocks. I suppose you can achieve the same thing in JADE but I think it's more fragmented (so probably harder to get right first time and more expensive to maintain).

Eric in Dunedin

by Torrie Moore >> Mon, 21 Feb 2000 23:35:22 GMT

I agree. Maybe I have been spoilt using exception handling in Delphi where you can do the following
begin

try
Do Something
except
clean up
apologise to user
end
end

The advantage of this method is that you method knows that a exception has occured and can handle it appropiately. I've yet managed to find a way your method can continue knowing an exception has occurred.

Torrie

by Robert Barr >> Tue, 15 Feb 2000 5:18:19 GMT

An afterthought - some useful warnings may be :

1 portability between NT and AIX (filesystem access, binary handling, external functions, etc).
2 item length mismatch on assignment between attributes, e.g stored data and form control
3 updating iterators or other control variables within a loop
4 use of goto statement
5 administrative warnings - no backup within 24 hours, reorg pending etc 6 poor (inefficient) contructs, esp performance-related
7 code metrics issues - code complexity, method length, indents(!), etc

Thx for input, Peter F

by Torrie Moore >> Tue, 15 Feb 2000 20:08:19 GMT

I've noticed that a lot of people ignore the compiler warnings and then come to grief later because of it. I would much rather have a list of warnings show up which tell me that I might be doing something stupid at compile time rather than spend hours later tracking down the bug. (See Writing solid code by Steve Maguire) Sure the ability to switch them off would apply to a lot of people, also the ability to put macros in your code to switch them off for a piece of code is also a good idea. I don't mean the warnings would stop you compiling code, they just tell you that you should think about what you are doing.

Torrie