1 / 62

AOS’03 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. Who’s who. Kasper G. Context-dependent objects (roles)

archer
Télécharger la présentation

AOS’03 session 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AOS’03session 1 Kasper B. Graversen

  2. 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

  3. Who’s who • Kasper G. • Context-dependent objects (roles) • Aspect-oriented programming • OO programming languages • Kasper • You (C) Kasper B. Graversen

  4. Who’s who • What’s your opinion on • the curriculum. • the form of evaluation. • any additional bright ideas? (C) Kasper B. Graversen

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. How well do we know Java • How are these lines read by Java?(1) is operator priorities, (2) is lexer rules • 2+3*4 -> 2+(3*4) or (2+3)*4 • i+++j -> i+(++j) or (i++)+j • Why does = always have lower priority than +,-,*, … ? (C) Kasper B. Graversen

  11. 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

  12. 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

  13. How well do we know Java • Method call semantics. Do we know what happens when we do a method call? • During the execution of foo, will “bar” always be printed on the screen? class A { void foo(){ bar() }; } void bar(){print(“bar”); } } (C) Kasper B. Graversen

  14. How well do we know Java 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(); • No. Here “surprise” is printed Why?? This is revealed later on in - stay tuned :-) (C) Kasper B. Graversen

  15. Programming Language history (C) Kasper B. Graversen

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. Simula 67 in general • Method binding • Static/early (non-virtual) • Dynamic/late (virtual, like in Java) • Argument passing in method calls • byvalue • by reference • or by name (C) Kasper B. Graversen

  23. 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

  24. 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

  25. 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

  26. Simula 67 expressions • IntVal := if A=B then IntVal + 1 else IntVal = 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

  27. 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

  28. Simula 67 class • Simula objects consists of • parameters • attributes • procedures • a body (C) Kasper B. Graversen

  29. 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

  30. method bindings & calls

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. Dynamic/late binding 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(); • we had a weird example (C) Kasper B. Graversen

  37. Dynamic/late binding 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 } } • But it makes more sense when changing it (C) Kasper B. Graversen

  38. Simula method call semantics 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(); • Has both kinds of bindings - so what happens here? (C) Kasper B. Graversen

  39. 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 Bsuper.v() (C) Kasper B. Graversen

  40. 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

  41. 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

  42. Binding of fields • Fields are not virtual in Simula/Java. • B’s x is said to shadowA‘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

  43. 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

  44. 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

  45. 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

  46. Binding of inner classes • So how about inner classes? • Example: an auto completer in Jedit for different langu-ages (C) Kasper B. Graversen

  47. 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

  48. 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

  49. 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

  50. Virtual labels 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; • chapter 18 from “An Introduction to Programming in Simula”, Rob Pooley (C) Kasper B. Graversen

More Related