Transcript session 1

AOS’03
session 1
Kasper B. Graversen
Today
• Who we are and who you are.
• Introduction
– Chapter 1 of “Interpretation…”
– How well do we really know Java?
• Walkthrough of Simula 67
– method binding
– calling mechanisms
– co-routines
(C) Kasper B. Graversen
2
Who’s who
• Kasper G.
– Context-dependent objects (roles)
– Aspect-oriented programming
– OO programming languages
• Kasper
• You
(C) Kasper B. Graversen
3
Who’s who
• What’s your opinion on
– the curriculum.
– the form of evaluation.
– any additional bright ideas?
(C) Kasper B. Graversen
4
Chapter 1 of “interpretation…”
• The extremes of OO languages
– prototypical languages (no classes exist)
– class-based languages (as we know from Java)
• 4 basic properties of OO languages
–
–
–
–
Encapsulation (confined data+functionality)
Inheritance (conceptual modeling + code re-use)
Polymorphism (references can refer to many forms)
Dynamic method binding (calls have dynamic ‘destination’)
(can be made to break in some languages)
– Notice the notion of types is not included!
(C) Kasper B. Graversen
5
Chapter 1 of “interpretation…”
• Pure vs. Impure languages
– Pure: All constructs relate to object orientation.
– Impure: Allows procedural programs
• OK characterization, but
– words carries too much value
– pure lang. may be impractical ie. Java’s maiin
method which is difficult to explain and seems
not to belong in a class.
• Languages are not just “Object Oriented”,
but degrees of Object
Orientednes.
(C) Kasper B. Graversen
6
How well do we know Java
• An understanding of a language can be
founded at levels
– Syntactic
• Valid names
• Reserved names
• Lexing conventions (chars => tokens)
– Semantic
• Inheritance, Name spaces, Method calls,
Types, casting rules, …
(C) Kasper B. Graversen
7
How well do we know Java
• How well do YOU think you know Java?
• Which of these are valid identifier names?
– Identifier
– $my_identifier
– $123
– 1booIdentifier
– doodi-doo
– %popID
(C) Kasper B. Graversen
8
How well do we know Java
• Knowing a language one should at least
know the meaning of its keywords.
• What does these reserved names mean?
– finally
– strictfp
– transient
– volatile
(C) Kasper B. Graversen
9
How well do we know Java
•
How are these lines read by Java?
(1) is operator priorities, (2) is lexer rules
1. 2+3*4
2. i+++j
•
-> 2+(3*4) or (2+3)*4
-> i+(++j) or (i++)+j
Why does = always have lower priority
than +,-,*, … ?
(C) Kasper B. Graversen
10
How well do we know Java
• What is printed on the screen when n=10
if(n > 100)
if(n > 200)
print(“a”);
else
print(“b”);
(C) Kasper B. Graversen
11
How well do we know Java
• Java has the notion of name spaces. Will
this program compile? why/why not.
– ns: packages, classes, methods and fields
public class String
{
String String;
String(){String = null;}
String(String String){this.String = String;}
String String(String String)
{
return new String(String);
}
}
(C) Kasper B. Graversen
12
How well do we know Java
• Method call semantics. Do we know what
happens when we do a method call?
class A {
void foo(){ bar() };
}
void bar(){print(“bar”); }
}
• During the execution of foo, will “bar”
always be printed on the screen?
(C) Kasper B. Graversen
13
How well do we know Java
• No. Here “surprise” is printed
class A {
void foo(){bar(); }
void bar(){print(“bar”); }
}
class B extends A {
void foo(){super(); }
void bar(){print(“surprise!”); }
}
B b = new B(); b.foo();
Why?? This is revealed later on in - stay tuned :-)
(C) Kasper B. Graversen
14
Programming Language history
(C) Kasper B. Graversen
15
Simula 67 in general
• Classes
– No destructor method (Java has destroy())
– inspect = instanceof + if-else
– qua = cast+error check
– in = instanceof
• Simula is an impure OO language
(C) Kasper B. Graversen
16
Simula 67 in general
• Block structures
– Nested classes and procedures
– Java only has nested classes and classes in methods
• Methods in methods are great
– decomposes a method in several parts without
having them running around in the class definition
– inner methods has access to the outside arguments
and variables - no passing of arguments…
(C) Kasper B. Graversen
17
Simula 67 in general
• Qualified references
– Not just pointing into memory
• better readability (a reference is now more than a name)
• enables type check (Limits what it can refer to)
• improves speed of code
• textual prefixing of classes = inheritance
– The least specific class code is executed first,
inner controlled the order of subclass execution.
– No super--either reuse old procedure or
completely rewrite it
(C) Kasper B. Graversen
18
Simula 67 in general
• Any block can be prefixed, ie. a procedure.
• Is used for importing libraries/modules
– more detailed and controlled usage
– ie. the class Simulation contains functionality for
simulation. Any procedure or class which needed
the simulation functionality thus were prefixed with
‘simulation’.
(C) Kasper B. Graversen
19
Simula 67 in general
• Access modifiers (applies to fields only)
– protected (as in Java)
– hidden protected (as private in Java)
– Appeared Jan. 1973
• An example of encapsulation without hiding (many CS
books seems not to be able to make this distinction).
(including [Craig02,p3: interpretation of oopl])
– One needs encapsulation before any hiding can take place.
(C) Kasper B. Graversen
20
Simula 67 in general
•
•
•
•
Imperatives: for, while, if-else
Labels and goto’s
Expressions can contain alternatives
Garbage collector
– Appeared in LISP in 1958
(C) Kasper B. Graversen
21
Simula 67 in general
• Method binding
– Static/early (non-virtual)
– Dynamic/late (virtual, like in Java)
• Argument passing in method calls
– by value
– by reference
– or by name
(C) Kasper B. Graversen
22
Simula 67 types
• Value Types (simple types in Java)
– Integer, Short Integer, Long,
Real, Boolean, Character
• Reference Types
– Object Reference, none, text,
”textconstant”, Notext
• Notice that text is not an object
• Conclusion
– VERY similar to Java - “its a matter of a few
name changes”
(C) Kasper B. Graversen
23
Simula 67 statements
• Assignment: :=
(i.e. x := 2)
• Reference Assignment: :(i.e. Queue :- New Head)
– Easier to read than = and == some argue
• Go to: Go to
• Block: Begin … End;
• If… Then…;
• If… Then… Else…;
(C) Kasper B. Graversen
24
Simula 67 statements
• Easy loop specification due to step and
until
• While: While … do … ;
• For: For … do … ;
Begin
Integer i;
For i:= 1 step 10 until 40
do OutInt(i,5);
End;
(C) Kasper B. Graversen
25
Simula 67 expressions
1. IntVal := if A=B then IntVal + 1
else IntVal = 2
2. (if A=B then Obj1 else Obj2).Val:= 6
•
Similar to Javas ? operator:
–
–
IntVal= (a==b ? intVal+1 : 2)
(a==b? obj1 : obj2).val = 6
(C) Kasper B. Graversen
26
Simula 67 procedures
Begin
Integer Procedure GCD(M, N); Integer M, N;
Begin
While M<>N do
If M<N then N := N - M else M := M - N;
GCD := M
End of GCD;
Integer A, B;
OutText("Enter an integer number: ");
OutImage; A := InInt;
OutText("Enter an integer number: ");
OutImage; B := InInt;
OutText("Greatest Common Divisor of your numbers is ");
OutInt(GCD(A,B), 4); OutImage;
End of Program;
(C) Kasper B. Graversen
27
Simula 67 class
• Simula objects consists of
–
–
–
–
parameters
attributes
procedures
a body
(C) Kasper B. Graversen
28
Simula 67 class
! Class with two parameters;
Class Rectangle (Width, Height); Real Width, Height;
Begin
Real Area, Perimeter; ! Attributes;
Procedure Update;
! Void procedure;
Begin
Area := Width * Height;
Perimeter := 2*(Width + Height)
End of Update;
Boolean Procedure IsSquare;
IsSquare := Width=Height;
Update;
! Body of rectangle;
OutText("Rectangle created: "); OutFix(Width,2,6);
OutFix(Height,2,6); OutImage
End of Rectangle;
(C) Kasper B. Graversen
29
method
bindings & calls
Polymorphism
one out of many definitions
• A reference can point to objects of different
types. The types must be the type of the
reference or its subtypes.
• ie. Object o = new Car()
• but not Car c = new Object()
(C) Kasper B. Graversen
31
Method binding
• When a method is called, it must be located.
• Static/early binding: Method definitions
and calls are explicit and statically defined
(at compile-time).
– “Works on types”
• Dynamic/late binding: Method calls are
determined by the currently bound object to
the reference at run-time.
– Possible due to polymorphism.
(C) Kasper B. Graversen
32
Static/early binding
• A continuation of how method calls works
in procedural languages (Fortran, Algol and
later Pascal and C, …)
=> may seem more “natural”
• C++ considers it an “optimization technique
as it yields faster method calls
• “most modern languages adopt dynamic binding
while older statically typed one generally prefer
static binding” [Craig02,p140: interpretation of oopl]
– Simula is both old and statically typed!
(C) Kasper B. Graversen
33
Dynamic/late binding
• Methods are considered to be virtual.
• In many languages the keyword virtual
must be denoted in front of the method
declaration (ie. Simula, C++, C#)
• Ensures it is the most specialized version of
the method which is invoked.
• two exceptions to this rule
– Beta works differently (invokes the LEAST specific first!)
– In multiple inheritance it is not clear in case of
a conflict which is the most specific
(C) Kasper B. Graversen
34
Dynamic/late binding
• so why is it nice?
• Instead of a general call, we call on the
‘actual object’. Eg. in a chess game we can
Piece[] arr…;
for(i=0..n)
arr[i].move()
• Supports the inheritance concept by
enabling an inheritance hierarchy to change
implementation in subclasses.
• Strengthens the concept of re-use.
(C) Kasper B. Graversen
35
Dynamic/late binding
• we had a weird example
class A {
void foo(){bar(); }
void bar(){print(“bar”); }
}
class B extends A {
void foo(){super(); }
void bar(){print(“surprise!”); }
}
B b = new B(); b.foo();
(C) Kasper B. Graversen
36
Dynamic/late binding
• But it makes more sense when changing it
class Player{
void play(int no){
… // sound stuff
info();
}
void info(){ … }
}
class VideoPlayer extends Player {
void play(int no){… super(); }
void info(){… // show on screen }
}
(C) Kasper B. Graversen
37
Simula method call semantics
• Has both kinds of bindings - so what happens here?
Class A
begin
procedure p; begin v() end
virtual prodecure v; …
end
A Class B ! B extends A
begin
procedure p; begin v; end
virtual prodecure v; …
end
A a :- new B();
a.p();
(C) Kasper B. Graversen
38
Simula/java method call semantics
• What happens here? (from a procedure in B)
(this qua A).v()
• or in Java
A a = new B()
((B) a).v()
• Or from within a method in B
super.v()
(C) Kasper B. Graversen
39
Java method call semantics
• All methods are virtual. What is the
consequence of that?
• Unambiguous method calls / uniformity!
– It is always the most specific (most specialized)
method which is invoked.
• Unambiguous in what fashion? Basically,
that every method call is indeterminable -not just some of them :-)
(C) Kasper B. Graversen
40
Binding of fields
• Most languages access methods and fields
differently. Are fields virtual in Simula/Java?
class A {
int x = 0;
void foo(){print(x);}
}
class B extends A {
int x = 1;
void foo(){ super(); }
}
B b = new B(); b.foo();
(C) Kasper B. Graversen
41
Binding of fields
• Fields are not virtual in Simula/Java.
• B’s x is said to shadow A‘s x, as it is
unreachable from outside B (and within
unless super is used).
• Why is it “natural” to have virtual methods
but not virtual fields? … Why is it defined
in such a way?
• The Java Language Specification (2nd ed)
seems not to give any answer.
• What do you think?
(C) Kasper B. Graversen
42
Binding of fields
• My interpretation is to view methods as
“actions” and fields as “data”.
– We want the most specific action (unless
declared using super)
– An action must be able to rely on its data
– The object should be ‘encapsulated’ -- data and
actions are confined.
• Others are be that
– there is no need for it
– efficiency
(C) Kasper B. Graversen
43
Virtual fields
• If we have virtual fields, the only new
functionality introduced is the ability to
change the type of fields.
• However, using accessor methods fields are
accessed using methods
=> field access becomes virtual.
• Can increase reusability since we have
functionality.
(C) Kasper B. Graversen
44
Virtual fields
class Vehicle {
int weight, gas;
int getWeight(){ return weight; }
setWeight(int w){…}
drive(int km) {gas-=km*(getWeight()/30)}
}
class Truck extend Vehicle{
Trailer trailer;
int getWeight(){ return super.getWeight()+
trailer.getWeight() }
loadTruck() {…}
loadTrailer() {…}
}
• No need to redefine drive()
• We can get into trouble, ie. setWeight is that the
truck or both truck and trailer? - how do to load the
truck only?
(C) Kasper B. Graversen
45
Binding of inner classes
• So how about inner classes?
• Example: an auto completer in Jedit for
different languages
(C) Kasper B. Graversen
46
Virtual inner classes
• Each language requires to listening to different
things: < for html, \, @ for LaTeX,…
class Popup {
KeyListener kl;
abstract class KeyListener {}
Popup(){kl = new KeyListener()}
}
class LaTeXPopup extends Popup {
class Keylistener {…} …}
class HTMLPopup extends Popup {
class Keylistener {…} …}
(C) Kasper B. Graversen
47
Virtual inner classes
• Inner classes are not virtual in Java.
• Solution is to use a (factory) method which
is virtual, which returns the proper listener.
• But does it make sense than fields not being
virtual?
(C) Kasper B. Graversen
48
Virtual labels
• Labels can be declared virtual in Simula. What do
you expect this to mean?
– A goto jumps to the most specific label definition
(C) Kasper B. Graversen
49
Virtual labels
• chapter 18 from “An Introduction to
Programming in Simula”, Rob Pooley
class SafeMths;
begin
class SafeDivide(Dividend,Divisor); real Dividend, Divisor;
virtual: label ZeroAction,Perform;
begin
real Result;
if Divisor=0 then go to ZeroAction;
go to Perform;
ZeroAction:
Divisor := 0.0001;
Inner;
Perform:
Result := Dividend/Divisor;
Complete:
end;
end;
(C) Kasper B. Graversen
50
Virtual labels
• continued…
begin
SafeDivide class MyDivide;
begin
ZeroActions:
Result := 9999999999999.9999999;
go to Complete;
end;
…
OutFix(new MyDivide(6,0).Result,4,20);
OutImage
(C) Kasper B. Graversen
51
Parameter passing
• Semantic models
– in
– out
– in & out
• We have different ways of implementing
passing of parameters
– by value
– by reference
– by name
(C) Kasper B. Graversen
52
Call by value
• When passing the argument, take a copy of it and pass it
on.
– Conceptually the parameter is write protected
– works fine for simple types and arrays
– very inefficient for arrays as the whole array is copied
(happens eg. in Pascal)
• What does it mean for objects?
– Illegal in Simula
– Shallow copy - only the object is copied, all its references are
not copied (eg. C++)
• could lead to unwanted sharing
– deep copy - the whole object graph is copied (bit wise copy of
the object)
(C) Kasper B. Graversen
53
Call by reference
• Pass the memory address of the parameter
– Changing the parameter within the method, changes it
outside the methods as well.
– Efficient transfer of arguments both in time and space
– Efficient data structure manipulation as e.g. swap
methods can efficiently be created (lists, trees etc).
• => ‘innocent looking’ methods can be really evil
– Method can have multiple return values
– All access are indirect since the address on the stack
must be loaded
int ret1, ret2;
foo(arg1, arg2, *ret1, *ret2)
void foo(int a, int b, int &r1, int &r2)
{ … r1 = …; r2 = … }
(C) Kasper B. Graversen
54
Call by name
• Pass an expression, a textual replacement,
which can be used in the method.
• Very flexible -- maybe too flexible, made
programs harder to read (and write)
• Slow
• Originates from Algol 60, used in Simula
procedure
begin
integer
for i =
sum =
end
A(exp, n)
sum = 0, i;
0 upto n step 1
sum + exp
(C) Kasper B. Graversen
55
Call by name
• Is used today in ‘text-centric‘ languages such
as velocity (used in apache) which has
macros using call by name
## A macro using Jensen's device: binding parameter $arg inside the macro
## binds the corresponding parameter variable in the expression $fun!
#macro(forall $list $arg $fun)
#foreach ($arg in $list)
$fun
#end
#end
#forall([2, 3, 5, 7, 11] $y "$y er et tal")
#forall([2, 3, 5, 7, 11] $y "#if ($y < 8) $y er mindre end otte #end")
#forall($snak.parameters $x "$x.Name has type $x.Type")
#forall($snak.parameters $x "The type of $x.Name is $x.Type")
<TABLE BORDER>
<TR><TH>Name<TH>Type #forall($snak.parameters $x “
<TR><TD>$x.Name<TD>$x.Type")
</TABLE>
(C) Kasper B. Graversen
56
Parameter passing in Java
• For simple types, call by value
• For references, call by copy reference
– call by value for the reference rather than what the
reference is pointing at.
• Since the reference is a copy, it can only
change the object referenced, not the original
pointer. [Sebesta01,p.365: Concepts of PL] is wrong!
void m(String s) { s = “bar”; }
String s = “foo”
m(s);
print(s);
(C) Kasper B. Graversen
57
Parameter passing in Java
• drawn
s1
“foo”
s1
“foo”
String s1 = “foo”
m(s1)
void m(String s2)
s2
s1
s2
“foo”
“bar”
(C) Kasper B. Graversen
{ s2 = “bar”; }
58
Co-routines
• Programming using threads is notoriously
difficult i.e.. synchronization issues
– because we have no control over the execution
• Most problems (including most simulations)
merely require processes to make progress over
time.
– Also called discrete simulation
(C) Kasper B. Graversen
59
Quasi parallelism
• Co-routines were originally named quasi
parallelism.
• Not real parallelism
– ‘threads’ must hand over control to the other ‘threads’
on a volunteer basis.
• control => no synchronization may be needed
• enables the programmer to specify the scheduling of tasks
(C) Kasper B. Graversen
60
Co-routines
• A co-routine is a procedure which can can
be resumed.
– leaves with a suspend() (think of it as a
special return in Java terms - return does not
exist in simula)
– When called again resume from where
suspended.
– Resembles ‘rendezvous' synchronization, the
difference is that rendezvous is used with
threads, hence the programmer do not have
control over the execution order.
(C) Kasper B. Graversen
61
The end…
(C) Kasper B. Graversen
62