Classes and Objects

1. Classes and Objects Per Brand

2. What is a Class? • A Class in Oz is a chunk (abstract data-type) that contains: • A collection of methods in a method table. • A description of the attributes that each instance of the class will possess. • Each attribute is a stateful cell that is accessed by the attribute-name, which is either an atom or an Oz-name. • A description of the features that each instance of the class will possess. • A feature is an immutable component (a variable) that is accessed by the feature-name, which is either an atom or an Oz-name. • Classes are stateless Oz-values. Contrary to languages like Smalltalk, or Java etc., they are just descriptions of how the objects of the class should behave.

3. Classes in Oz • Oz supports object-oriented programming following the methodology outlined above. • The class Counter defined earlier has the syntactic form class Counterattr valmeth browse {Browse @val}endmeth inc(Value) val <- @val + Valueendmeth init(Value) val <- Valueendend

4. A class X is defined by: • classX ... end. • Attributes are defined using the attribute-declaration part before the method-declaration part: • attrA1 ... AN • Then follows the method declarations, each has the form: • methESend • The expression Eevaluates to a method head, which is a record whose label is the method name. • An attribute A is accessed using @A. • An attribute is assigned a value using A <- E • A class can be defined anonymously by: • X=class $ ... end.

5. Example • The following shows how an object is created from a class using the procedure New/3, whose first argument is the class, the second is the initial method, and the result is the object. • New/3 is a generic procedure for creating objects from classes. declare C = {New Counter init(0)}{C browse}{C inc(1)}{C browse}

6. Static method calls • Given a class and a method head m(…), a static method-call has the following form:C,m(…) • Invokes the method defined in the class argument. • A static method call can only be used inside class definitions. • The method call takes the current object denoted by self as implicit argument. • The method m could be defined the class C, or inherited from a super class.

7. Attributes • Stateful (may be updated by ‘<-’) • Initialized at object creation time, e.g.class Account attr balance:0 meth … end … end • Correspond to instance variables in OO

8. Features • Features are components that are specified in the class declaration: • classCfrom …feata1 … an …end • As in a record, a feature of an object has an associated field. The field is a logic variable that can be bound to any Oz value (including cells, objects, classes etc.). • Features of objects are accessed using the infix ´.´ operator.

9. Features class ApartmentC from BaseObjectmeth init skip endendclass AptC from ApartmentCfeat streetName: york streetNumber:100 wallColor:white floorSurface:woodend Apt = {New AptC init} {Browse Apt.streetName}

10. Feature Initialization • Features initialized at the class-definition time: • All instances of the class will have the features of the class, with the values defined in the class. • Example: following program will display york twice. • declare Apt1 Apt2Apt1 = {New AptC init}Apt2 = {New AptC init}{Browse Apt1.streetName}{Browse Apt2.streetName}

11. Feature Initialization • Uninitialized features: • classMyAptC1 from ApartmentCfeat streetNameend • Whenever an instance is created, the field of the feature is assigned a new fresh variable. • declareApt3 Apt4Apt3 = {New MyAptC1 init}Apt4 = {New MyAptC1 init}Apt3.streetName = kungsgatanApt4.streetName = sturegatan • Will bind the feature streetName of object Apt3 to the atom kungsgatan, and the corresponding feature of Apt4 to the atom sturegatan.

12. Feature Initialization • Features initialized to a variable or an Oz-value that contains a variable: • All instances of the class will share the same variable. • class MyAptC1 from ApartmentCfeatstreetName:_enddeclare Apt1 Apt2Apt1 = {New MyAptC1 init}Apt2 = {New MyAptC1 init}{Show Apt1.streetName} %% Shows _{Show Apt2.streetName} %% Shows _Apt1.streetName = york {Show Apt1.streetName} %% Shows york{Show Apt2.streetName} %% Shows york • If not initialized to a variable then last show will show _.

13. Inheritance class Account attr balance:0 meth transfer(Amount) balance<- @balance+Amount end meth getBal(B) B = @balance end end A={New Account transfer(100)}

14. Inheritance II Conservative extension class VerboseAccount fromAccount meth verboseTransfer(Amount) {self transfer(Amount)} {Show @balance} end end Non-Conservative extension class AccountWithFee fromVerboseAccount attr fee:5 meth transfer(Amount) VerboseAccount,transfer(Amount-@fee) end end

15. Inheritance III • Classes may inherit from one or several classes appearing after the keyword: from. • A class B is a superclass of a class A if: • B appears in the from declaration of A, or • B is a superclass of a class appearing in the from declaration of A. • The methods (attributes and features) available in a class C (i.e. visible) are defined through a precedence relation on the methods that appear in the class hierarchy: the overriding relation: • A method in a class C overrides any method, with the same label, in any super class of C.

16. SuperClass relation • SuperClass relation is directed and acyclic. C

17. SuperClass relation • SuperClass relation is directed and acyclic. • After striking out all overridden methods each remaining method should have a unique label and is defined only in one class in the hierarchy. C

18. Inheritance relation m m A (valid hierarchy) m C (invalid hierarchy)

19. Multiple Inheritance Example class Account attr balance:0 meth transfer(Amount) balance<- @balance+Amount end meth getBal(B) B = @balance end end class Customer feat name meth init(N) self.name=N end end class CustomerAccount from Customer Account end A={New CustomerAccount init}

20. Illegal inheritance class Account attr balance meth init(Amount) balance<- Amount end meth transfer(Amount) balance<- @balance+Amount end meth getBal(B) B = @balance end end class Customer feat name meth init(N) self.name=N end end class CustomerAccount from Customer Account end

21. Legal inheritance class Account attr balance meth init(Amount) balance<- Amount end meth transfer(Amount) balance<- @balance+Amount end meth getBal(B) B = @balance end end class Customer feat name meth init(N) self.name=N end end class CustomerAccount from Customer Account meth init(N A) Customer,init(N) Account,init(A) end end

22. Encapsulation with Names private localPAttr PMeth in {NewName PAttr} {NewName PMeth} classC1 attr !PAttr meth !PMeth ... end end end classC1 attrPAttr methPMeth ... end end

23. Encapsulation with Names protected localProtMethin {NewName PMeth} classC2 attrprotMeth:!PMeth meth!PMeth ... end methotherMethod {self@protMeth} end end end classC2 attrprotMeth:PMeth methPMeth ... end methotherMethod {self@protMeth} end end

24. Encapsulation with Names protected-2 localPAttr PMeth in {NewName PMeth} classC1 meth !PMeth ... end end classC2 from C1 meth x {self!PMeth(a)} end end end

25. Virtual Methods class Account attr balance meth init %% this method is supposed to be overridden raise virtualMethod(‘Account’)end end meth transfer(C) ... end end class PersonAccount from Account feat name meth init(N C) ... end end class CompanyAccount from Account meth init(N A) ... end end

26. Interfaces • Method 1: Use multiple inheritance with virtual method classes • Method 2: Use records/modules fun{CreateImplementation Implementation Interface1 Interface2} Aux1 Aux2 All Rec inAux1={List.filter Interface1 proc{$ X} X\==implements end} Aux2={List.filter Interface2 proc{$ X} X\==implements end} Aux={List.append Aux1 Aux2} {Record.make implementation implements|All Rec} Rec.implements=All for X in All do Rec.X=Implementation.X end Rec end

27. Interfaces-2 • Method 1: Use multiple inheritance with virtual method classes • Method 2: Use records/modules declare class C meth init … end meth a … end meth b … end meth c … end meth d … end end O={New C init} X={CreateImplementation implements(a:proc{$ X}{Obj X} end b:… c:… d:… ) [a b implements] [c d implements]}

28. Classes as First Class Values fun {MakeClassAcountWithFee Fee} class $ %% Fee is in closure fromAccount meth init(Amount) Account,init(Amount-Fee) end end end Account={MakeClassAccountWithFee 100} {New Account init(1000)}

29. First Class Attribute Identifiers OldValue = attr <- NewValue Atomic Exchange meth dynAssign(Attr NewValue Msg) OldValue = Attr <- NewValue in {self Msg} Attr <- OldValue end

30. Objects and Concurrency • Threads may communicate through message passing or through a shared object space. • Communication through shared objects requires the ability to serialize concurrent operations on objects so that the object state is kept coherent after each such an operation. • In Oz, we separate the issue of acquiring exclusive access of an object from the object system. • This gives us the ability to perform coarse-grain atomic operation of a set of objects, a very important requirement in distributed database system.

31. Thread-reentrant locking • In Oz, the computational unit is the thread. Therefore an appropriate locking mechanism should grant exclusive access rights to threads. • A thread-reentrant lock allows the same thread to reenter a dynamically nested critical region guarded by the same lock. • Such a lock can be acquired by at most one thread at a time. • Concurrent threads that attempt to get the same lock are queued. • When the lock is released, it is granted to the thread standing first in line etc.

32. Locking Objects • We may declare in the class that its instance objects may use a default lock existing in the object is created • A class with an implicit lock is declared as follows: • classCfrom ....prop locking ....end • This does not automatically lock the object when one of its methods is called. Instead we have to use the construct: • lockSend • inside any method to guarantee exclusive access when S is executed.

33. Locking objects • Remember that our locks are thread-reentrant. This implies that: • if we take all objects that we have constructed and enclose each method body with lock … end, and • our program executes with only one thread, then • the program will behave exactly as before • Java also has thread-reentrant locking • without this callbacks could deadlock the program

34. Example class Account proplockingfeatnr transCostattr amount meth init(A Nr C)self.nr=Nramount<-A self.transCost=C end meth sub(A) lock amount<-@amount-A end end meth transferTo(X A)lock {X transferFrom(self A)} {self sub(A)} end end meth transferFrom(X A)lock {X sub(self.transCost)} {self add(A)} end end end proc{Transfer Obj Obj2 A} case Obj.nr<Obj.nr2 then {Obj transferTo(Obj2 A)} else … end end A={New Account init(1000 a 10)} B={New Account init(500 b 100)} {A transferTo(B 300)}

35. A concurrent FIFO channel • A concurrent channel shared among an arbitrary number of threads. • Any producing thread may put information in the channel asynchronously. • A consuming thread has to wait until information exists in the channel. • Waiting threads are served fairly. • This program relies on the use of logical variables to achieve the desired synchronization. • The method put/1 inserts an element in the channel. • The method get/1 will wait until an element is put in the channel. • Multiple consuming threads will reserve their place in the channel, thereby achieving fairness.

36. {Wait I} is done outside an exclusive region. If waiting was done inside lock ... end the program would deadlock. • A rule of thumb: Do not wait inside an exclusive region, if the waking-up action has to acquire the same lock. class Channel proplockingattr f rmeth init X inf <- X r <- X %% 2 refs to same varendmeth put(I) X inlock @r=I|X r<-X endendmeth get(?I) X inlock @f=I|X f<-X end {Wait I} %% OBS!! wait outside lock end end

37. Events • A class that defines the notion of event and event operations notify(Event) and wait(Event) by specializing the class Channel. • classEvent from Channelmeth wait Channel , get(_)endmeth notify Channel , put(unit)endend

38. Unit Buffer • In Oz, there is a simple way to write a UnitBuffer class. This is due to the combination of objects and logic variable. No additional locking is needed. • class UnitBuffer attr prodq buffermeth init buffer <- {New Channel init} prodq <- {New Event init} {@prodq notify} %Buffer is emptyendmeth put(I) {@prodq wait} {@buffer put(I)}endmeth get(?I) {@buffer get(I)} {@prodq notify}endend • Contrast this program to others written in traditional language like Java (see tutorial)!

39. Bounded Buffer • Simple generalization of the above program leads to an arbitrary size bounded buffer class. The put and get methods are the same as before. Only the initialization method is changed. class BoundedBuffer from UnitBufferattr prodq buffermeth init(N) buffer <- {New Channel init} prodq <- {New Event init} {For 1 N 1 proc {$ _} {@prodq notify} end}endend

40. Active Objects • An active object is a thread (process) whose behavior is described by a class definition. • Communication with active objects is though asynchronous message passing. • An active object reacts to received messages by executing the corresponding methods in its associated class. • An active object executes one method at a time. Therefore locking is not needed for methods performed by an active object. • The interface to an active object is through Oz ports. • Clients of an active object send messages to the object by sending messages to its associated port. • We will show how to create generically this abstraction.

41. Active Objects • Since active objects may be used as servers receiving messages from clients though a network we call this abstraction the server abstraction. • To create a server S from a class Classwe execute:S = {NewServer Classinit} • initis the initial object construction method. • To get the basic idea we show first a simplified form of the NewServer function. The following function: • creates a port Port, • creates an object Object, and finally • creates a thread that serves messages sent to the port, by applying the corresponding class methods.

42. Simplified Server fun {NewServer Class Init}S % The stream of the port Port = {NewPort S} Object = {New Class Init}inthread {ForAll S proc{$ M} {Object M} end}endPortend

43. Simplified Server-2 class Registry attr reg:nil meth init skip endmeth Unreg(X L Out) case L of !X|More then Out=More [] Other|More then Out1 in Out=X|Out1 {self Unreg(X More Out1)} else Out=nil endmeth reg(X) reg<-X|@reg end meth unreg(X) {self Unreg(X @reg Out} reg<-Out end end Reg={NewServer Registry init}

44. We would like to add the ability of terminating the thread by making a protected method Close accessible to methods in Class. This leads us to the following extension of the above function. We use the exception handling mechanism to jump out of the receiving loop. localCloseException = {NewName} %% added classServerattrclose:Closemeth Close raise !CloseException end end in fun {NewServer Class init}S % The stream of the port Port = {NewPort S} Object = {New class $ fromServer Classend init}inthreadtry {ForAll S proc{$ M} {Object M} end}catch !CloseException then skip endendPortendend