Snow Chain-Integrated Tire for a Safe Drive on Winter Roads
Objects arent records with byte codes on the side
1. So You Think Objects Are Records
With Byte Codes On The Side?
T
h
i
n
k
A
g
a
i
n
2. Where Do Objects Fit?
As a vehicle for implementing programs.
So You Think Objects Are Records With Byte Codes On The Side? 2
3. Where Do Objects Fit?
As a vehicle for implementing programs.
As a vehicle for modeling actual business entities and
the diverse, complex rules that govern their
interpretation and use.
So You Think Objects Are Records With Byte Codes On The Side? 3
4. How Do We View Objects?
Traditional thinking holds that objects are the managers
and clients of state stored in data base records.
So You Think Objects Are Records With Byte Codes On The Side? 4
5. How Do We View Objects?
Traditional thinking holds that objects are the managers
and clients of state stored in data base records.
An intuitively appealing conceptual model...
So You Think Objects Are Records With Byte Codes On The Side? 5
6. How Do We View Objects?
Traditional thinking holds that objects are the managers
and clients of state stored in data base records.
An intuitively appealing conceptual model...
… that is inherently external to the data base.
So You Think Objects Are Records With Byte Codes On The Side? 6
7. How Do We Implement Objects?
Traditional thinking holds that objects are records with
methods on the side.
So You Think Objects Are Records With Byte Codes On The Side? 7
8. How Do We Implement Objects?
Traditional thinking holds that objects are records with
methods on the side.
An intuitively appealing conceptual model...
So You Think Objects Are Records With Byte Codes On The Side? 8
9. How Do We Implement Objects?
Traditional thinking holds that objects are records with
methods on the side.
An intuitively appealing conceptual model...
… that insists on viewing the world one individual at a
time.
So You Think Objects Are Records With Byte Codes On The Side? 9
10. So What’s Wrong With That?
It may work for clients that consume relatively small
amounts of data...
So You Think Objects Are Records With Byte Codes On The Side? 10
11. So What’s Wrong With That?
It may work for clients that consume relatively small
amounts of data...
It may work for programs…
So You Think Objects Are Records With Byte Codes On The Side? 11
12. So What’s Wrong With That?
It may work for clients that consume relatively small
amounts of data...
It may work for programs…
… but it leaves the hard problem of implementing
scaleable business objects, particularly entity objects, as
an exercise for the ‘reader’.
So You Think Objects Are Records With Byte Codes On The Side? 12
13. So Where Do We Go Next?
Establishing Principles
Starting At The Top
Questioning Assumptions
Developing a New Foundation
So You Think Objects Are Records With Byte Codes On The Side? 13
14. Establishing Principles
From an application perspective:
comprehensibility
» most applications we encounter are ultimately
developed by involved, business knowledgeable users,
not programmers.
integration
» solving interface and impedance matching problems
is a jargon laden waste of time.
So You Think Objects Are Records With Byte Codes On The Side? 14
15. Establishing Principles
From a technology perspective:
theory
» a collection centric theory of operation is critical to
achieving reliable application scalability and
deployment.
integration
» solving interface and impedance matching problems
is a jargon laden waste of time.
So You Think Objects Are Records With Byte Codes On The Side? 15
16. Establishing Principles
From any perspective:
generality
» most applications are a collection of many simple,
hard problems.
» it is impossible to overstate the complexity of even
the simplest looking applications.
So You Think Objects Are Records With Byte Codes On The Side? 16
17. Starting At The Top
Without creating an application specific technology,
start with an understanding of how entity based
applications work and what needs to be in place in
order to create them.
So You Think Objects Are Records With Byte Codes On The Side? 17
18. For Example, …
Account defineMethod: [ | getHoldingsOverlap |
A mutual fund analysis !lowerPct <- pctEq * 0.8; !upperPct <- … ;
holdings send: [security].
system powered by our select: [type isEquity].
technology needs to collectListElementsFrom: [holdings].
groupedBy: [account].
rank funds based on select: [pctEq >= ^my lowerPct
&& pctEq <= ^my upperPct].
the overlap of their extendBy: [
holdings with another, !xref <- ^my holdings;
!ofactor <- groupList total: [
arbitrarily chosen, percentOfPort min: (^my xref at: security.
fund: ]
percentOfPort)
].
sortDown: [ofactor]
];
So You Think Objects Are Records With Byte Codes On The Side? 18
19. Collections Are Everywhere
Account defineMethod: [ | getHoldingsOverlap |
Query and collection !lowerPct <- pctEq * 0.8; !upperPct <- … ;
holdings send: [security].
operations are select: [type isEquity].
embedded throughout collectListElementsFrom: [holdings].
groupedBy: [account].
this application’s logic, select: [pctEq >= ^my lowerPct
&& pctEq <= ^my upperPct].
not simply at the extendBy: [
‘database’ end of a data !xref <- ^my holdings;
!ofactor <- groupList total: [
pipeline. percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];
So You Think Objects Are Records With Byte Codes On The Side? 19
20. Detail Counts
Account defineMethod: [ | getHoldingsOverlap |
The collection level !lowerPct <- pctEq * 0.8; !upperPct <- … ;
holdings send: [security].
detail associated with select: [type isEquity].
an object is just as collectListElementsFrom: [holdings].
groupedBy: [account].
important as its select: [pctEq >= ^my lowerPct
&& pctEq <= ^my upperPct].
summary information extendBy: [
and must be just as !xref <- ^my holdings;
!ofactor <- groupList total: [
easily accessible. percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];
So You Think Objects Are Records With Byte Codes On The Side? 20
21. Information Is Dynamic
Account defineMethod: [ | getHoldingsOverlap |
New collections of !lowerPct <- pctEq * 0.8; !upperPct <- … ;
holdings send: [security].
data, complete with select: [type isEquity].
new and additional collectListElementsFrom: [holdings].
groupedBy: [account].
properties, need to be select: [pctEq >= ^my lowerPct
&& pctEq <= ^my upperPct].
created, used, and extendBy: [
returned ‘on-the-fly’. !xref <- ^my holdings;
!ofactor <- groupList total: [
percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];
So You Think Objects Are Records With Byte Codes On The Side? 21
22. Complexity Is Hidden
Account defineMethod: [ | getHoldingsOverlap |
Many complex details !lowerPct <- pctEq * 0.8; !upperPct <- … ;
holdings send: [security].
are hidden, including select: [type isEquity].
the fact that important collectListElementsFrom: [holdings].
groupedBy: [account].
data used in even this select: [pctEq >= ^my lowerPct
&& pctEq <= ^my upperPct].
‘simple’ application is extendBy: [
time-varying and, !xref <- ^my holdings;
!ofactor <- groupList total: [
therefore, context percentOfPort min: (^my xref at: security.
sensitive. ]
percentOfPort)
].
sortDown: [ofactor]
];
So You Think Objects Are Records With Byte Codes On The Side? 22
23. Complexity Is Embeddable
It is impossible to anticipate how encapsulated
functionality will be used:
TRoweFunds do: [^self getHoldingsOverlap first: 5 . do: […] ]
^today to: ^today - 1 years by: 1 quarterEnds. evaluate: [
MagellanFund getHoldingsOverlap do: [ … ]
];
So You Think Objects Are Records With Byte Codes On The Side? 23
24. Starting At The Top, Epilogue …
The functionality required by entity based applications
profoundly affects all of the technologies it touches
without fitting neatly into any of them.
So You Think Objects Are Records With Byte Codes On The Side? 24
25. … And Prologue:
Time to start thinking outside the box and questioning
assumptions, ...
So You Think Objects Are Records With Byte Codes On The Side? 25
26. Questioning Assumptions
From an application perspective:
Entity based applications fit into a neat little
box.
From a technology perspective:
That which an application sees and
manipulates is the way it really works.
So You Think Objects Are Records With Byte Codes On The Side? 26
27. Questioning Assumptions
And its corollaries:
Who said sets are defined by the elements they keep?
Who said objects are records?
So You Think Objects Are Records With Byte Codes On The Side? 27
28. Who said sets are defined by the
elements they keep?
Sets have come to be known as ‘unique-ifers of things’.
This operational definition is understandable given
everyone’s intuitive concept of a set
So You Think Objects Are Records With Byte Codes On The Side? 28
29. Set Elements Don’t Matter, …
The intuitive definition of sets in terms of their
elements imparts unnecessary structure.
The structure it does impart is misplaced anyway.
So You Think Objects Are Records With Byte Codes On The Side? 29
30. … And Sets Are Structureless
A better intuitive definition
for a set is that it is MySetOf3
‘collection of distinguishable
things’, without reference to
the particular things:
my set of three things
the Integers
TheIntegers
So You Think Objects Are Records With Byte Codes On The Side? 30
31. But Where Are The Elements?
But where do you
represent the fact that a MySetOf3
particular set of three
things ‘contains’ the
elements {4, 14, 34}?
TheIntegers
So You Think Objects Are Records With Byte Codes On The Side? 31
32. In A Morphism, …
m0
1→4
MySetOf3
2 → 14
3 → 34
m0
TheIntegers
So You Think Objects Are Records With Byte Codes On The Side? 32
33. That, Along With The Set, Is
Unique Up To Isomorphism, …
m0 i01 i02
1→4 1→3 1→2
MySetOf3
2 → 14 2→1 2→3
3 → 34 3→2 3→1 i01
i10 i12 i10 m0
1→2 1→3 i02 i20 m1
2→3 2→1 S1
3→1 3→2
i20 i21 m2 i12 i21
1→3 1→2 1 → 34 m2 TheIntegers
2→1 2→3 2→4
3→2 3→1 3 → 14 S2
So You Think Objects Are Records With Byte Codes On The Side? 33
34. Only Morphism Structure Matters
The properties and internal structure of morphisms and
families of morphisms:
express constraints
implement operations
characterize transformations and relationships
provide an algebraic framework
These roles are not mutually exclusive.
So You Think Objects Are Records With Byte Codes On The Side? 34
35. Morphisms Express Constraints
Morphism structure
expresses constraints: MySetOf3
m0, as the ‘element’ specifier
for MySetOf3, must be m0
injective.
m0
TheIntegers
1→4
2 → 14
3 → 34
So You Think Objects Are Records With Byte Codes On The Side? 35
36. Morphisms Implement Operations
Morphism structure supports
operation implementation: MySetOf3
m1 = m0 º i10
i10 m0
∀j∈S1 m1[j] = m0[i10[j]]
m1
S1
i10 m0 m1
1→2 1→4 1 → 14 TheIntegers
2→3 2 → 14 2 → 34
3→1 3 → 34 3→4
So You Think Objects Are Records With Byte Codes On The Side? 36
37. Morphisms Characterize
Transformations and Relationships
Composition Product (Projection)
pr0
g f pr1
…
prn
fºg
Partition Disjoint Union
Values Elements in0
v=kºe in1
…
k e inn
Collections
So You Think Objects Are Records With Byte Codes On The Side? 37
38. Morphisms Characterize
Transformations and Relationships
Instantiation Deletion
Sv0 Sv0
in in
Sv1 Sv1
Insertion Join
So You Think Objects Are Records With Byte Codes On The Side? 38
39. So Where Are We?
Structureless sets.
Information bearing morphisms.
What does this have to do with objects and data bases?
So You Think Objects Are Records With Byte Codes On The Side? 39
40. Structureless Sets Denote Things
Structureless sets
Account
represent sets of
distinguishable things: AccountId
the set of Account
objects Holding
the set of Holding
objects
SecurityId
the set of Security
objects Security
So You Think Objects Are Records With Byte Codes On The Side? 40
41. Morphisms Hold Values
Information bearing
Account
morphisms hold id
property values … AccountId
accountId
Holding
securityId
SecurityId
id
Security
So You Think Objects Are Records With Byte Codes On The Side? 41
42. … Including Navigational Values
…including the values of
Account
navigational properties. id
AccountId
account
accountId
Holding
securityId
security
SecurityId
id
Security
So You Think Objects Are Records With Byte Codes On The Side? 42
43. … Without Violating Theory
…while remaining on
Account
firm theoretical id
account
ground. AccountId
accountId
Holding
securityId
SecurityId
security
id
Security
So You Think Objects Are Records With Byte Codes On The Side? 43
44. Properties Can Be Polymorphic
Properties are usually
Account
polymorphic… id
AccountId
account
accountId
Holding
securityId
security
SecurityId
id
Security
So You Think Objects Are Records With Byte Codes On The Side? 44
45. So Morphisms Need Fine Structure
Portfolio super
Account
Aggregate
Index id
AccountId
in0 in1 in2
Holding
account accountId
securityId
security
SecurityId
… like disjoint union. id
Security
So You Think Objects Are Records With Byte Codes On The Side? 45
46. Properties Can Be Time-Varying
Properties often
Account
express time varying id
relationships. account
AccountId
We won’t go there right accountId
now except to say that the Holding
securityId
fine structure gets even security
richer. SecurityId
id
Security
price
So You Think Objects Are Records With Byte Codes On The Side? 46
47. It Computes …
Account
id
Partition
AccountId
account
Compose accountId
Holding
collectListElementsFrom: [holdings]. securityId
groupedBy: [account]. security
…
extendBy: [ SecurityId
… id
!ofactor <- groupList total: […] Security
…
];
So You Think Objects Are Records With Byte Codes On The Side? 47
48. In Parallel …
Portfolio super
Account
Aggregate
Index id
AccountId
in0 in1 in2
Holding
accountId
securityId
security
SecurityId
Compose/Join id
Security
So You Think Objects Are Records With Byte Codes On The Side? 48
49. But All Of This Is Well Hidden …
Account defineMethod: [ | getHoldingsOverlap |
All a user sees is a !lowerPct <- pctEq * 0.8; !upperPct <- … ;
holdings send: [security].
conventional object select: [type isEquity].
oriented programming collectListElementsFrom: [holdings].
groupedBy: [account].
language. select: [pctEq >= ^my lowerPct
&& pctEq <= ^my upperPct].
extendBy: [
!xref <- ^my holdings;
!ofactor <- groupList total: [
percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];
So You Think Objects Are Records With Byte Codes On The Side? 49
50. This Is Necessarily An Overview
What you have seen is an overview of a straightforward
but non-trivial technology.
The principles described here easily address the data
definition and manipulation needs of a general purpose,
integrated data base management, data base
programming environment.
So You Think Objects Are Records With Byte Codes On The Side? 50
51. Questioning Assumptions - Reprise
From an application perspective:
Entity based applications fit into a neat little
box.
From a technology perspective:
That which an application sees and
manipulates is the way it really works.
So You Think Objects Are Records With Byte Codes On The Side? 51
52. By The Way, What Are Objects?
The theory underlying all of this is Category Theory.
By the way, objects are sub-categories of the concrete
category Set.
So You Think Objects Are Records With Byte Codes On The Side? 52
53. Where Are We?
commercially proven
solid theoretical underpinnings
unified, inherently parallel data base programming
language integration
So You Think Objects Are Records With Byte Codes On The Side? 53
54. And, Of Course …
Objects are records with byte codes on the side?
It Ain’t Necessarily So.
So You Think Objects Are Records With Byte Codes On The Side? 54