1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
# file: runme.py
# This file illustrates the cross language polymorphism using directors.
import example
# CEO class, which overrides Employee::getPosition().
class CEO(example.Manager):
def __init__(self, name):
example.Manager.__init__(self, name)
def getPosition(self):
return "CEO"
# Create an instance of our employee extension class, CEO. The calls to
# getName() and getPosition() are standard, the call to getTitle() uses
# the director wrappers to call CEO.getPosition. e = CEO("Alice")
e = CEO("Alice")
print e.getName(), "is a", e.getPosition()
print "Just call her \"%s\"" % e.getTitle()
print "----------------------"
# Create a new EmployeeList instance. This class does not have a C++
# director wrapper, but can be used freely with other classes that do.
list = example.EmployeeList()
# EmployeeList owns its items, so we must surrender ownership of objects
# we add. This involves first calling the __disown__ method to tell the
# C++ director to start reference counting. We reassign the resulting
# weakref.proxy to e so that no hard references remain. This can also be
# done when the object is constructed, as in: e =
# CEO("Alice").__disown__()
e = e.__disown__()
list.addEmployee(e)
print "----------------------"
# Now we access the first four items in list (three are C++ objects that
# EmployeeList's constructor adds, the last is our CEO). The virtual
# methods of all these instances are treated the same. For items 0, 1, and
# 2, both all methods resolve in C++. For item 3, our CEO, getTitle calls
# getPosition which resolves in Python. The call to getPosition is
# slightly different, however, from the e.getPosition() call above, since
# now the object reference has been "laundered" by passing through
# EmployeeList as an Employee*. Previously, Python resolved the call
# immediately in CEO, but now Python thinks the object is an instance of
# class Employee (actually EmployeePtr). So the call passes through the
# Employee proxy class and on to the C wrappers and C++ director,
# eventually ending up back at the CEO implementation of getPosition().
# The call to getTitle() for item 3 runs the C++ Employee::getTitle()
# method, which in turn calls getPosition(). This virtual method call
# passes down through the C++ director class to the Python implementation
# in CEO. All this routing takes place transparently.
print "(position, title) for items 0-3:"
print " %s, \"%s\"" % (list.get_item(0).getPosition(), list.get_item(0).getTitle())
print " %s, \"%s\"" % (list.get_item(1).getPosition(), list.get_item(1).getTitle())
print " %s, \"%s\"" % (list.get_item(2).getPosition(), list.get_item(2).getTitle())
print " %s, \"%s\"" % (list.get_item(3).getPosition(), list.get_item(3).getTitle())
print "----------------------"
# Time to delete the EmployeeList, which will delete all the Employee*
# items it contains. The last item is our CEO, which gets destroyed as its
# reference count goes to zero. The Python destructor runs, and is still
# able to call self.getName() since the underlying C++ object still
# exists. After this destructor runs the remaining C++ destructors run as
# usual to destroy the object.
del list
print "----------------------"
# All done.
print "python exit"
|
