Objects arent records with byte codes on the side

So You Think Objects Are Records
With Byte Codes On The Side?
T
h
i
n
k
A
g
a
i
n

Where Do Objects Fit?
As a vehicle for implementing programs.

So You Think Objects Are Records With Byte Codes On The Side? 2

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.


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.


How Do We Implement Objects?
Traditional thinking holds that objects are records with
methods on the side.


… that insists on viewing the world one individual at a
time.


So What’s Wrong With That?
It may work for clients that consume relatively small
amounts of data...


amounts of data...
It may work for programs…


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 Where Do We Go Next?
Establishing Principles
Starting At The Top
Questioning Assumptions
Developing a New Foundation


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.


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.


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.


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.


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]
];


Collections Are Everywhere
Query and collection !lowerPct <- pctEq * 0.8; !upperPct <- … ;
operations are select: [type isEquity].
embedded throughout collectListElementsFrom: [holdings].
this application’s logic, select: [pctEq >= ^my lowerPct
not simply at the extendBy: [
‘database’ end of a data !xref <- ^my holdings;
pipeline. percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];


Detail Counts
The collection level !lowerPct <- pctEq * 0.8; !upperPct <- … ;
detail associated with select: [type isEquity].
an object is just as collectListElementsFrom: [holdings].
important as its select: [pctEq >= ^my lowerPct
summary information extendBy: [
and must be just as !xref <- ^my holdings;
easily accessible. percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];


Information Is Dynamic
New collections of !lowerPct <- pctEq * 0.8; !upperPct <- … ;
data, complete with select: [type isEquity].
new and additional collectListElementsFrom: [holdings].
properties, need to be select: [pctEq >= ^my lowerPct
created, used, and extendBy: [
returned ‘on-the-fly’. !xref <- ^my holdings;
percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];


Complexity Is Hidden
Many complex details !lowerPct <- pctEq * 0.8; !upperPct <- … ;
are hidden, including select: [type isEquity].
the fact that important collectListElementsFrom: [holdings].
data used in even this select: [pctEq >= ^my lowerPct
‘simple’ application is extendBy: [
time-varying and, !xref <- ^my holdings;
therefore, context percentOfPort min: (^my xref at: security.

sensitive. ]
percentOfPort)

].
sortDown: [ofactor]
];


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: [ … ]
];


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.


… And Prologue:
Time to start thinking outside the box and questioning
assumptions, ...


Entity based applications fit into a neat little
box.
That which an application sees and
manipulates is the way it really works.


And its corollaries:
Who said sets are defined by the elements they keep?
Who said objects are records?


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


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.


… 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


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


In A Morphism, …
m0
1→4
MySetOf3
2 → 14
3 → 34
m0

TheIntegers


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


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.


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


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


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


Morphisms Characterize
Transformations and Relationships
Instantiation Deletion
Sv0 Sv0
in in

Sv1 Sv1

Insertion Join


So Where Are We?
Structureless sets.
Information bearing morphisms.
What does this have to do with objects and data bases?


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


Morphisms Hold Values
Information bearing
Account
morphisms hold id
property values … AccountId

accountId
Holding
securityId

SecurityId
id
Security


… Including Navigational Values
…including the values of
Account
navigational properties. id
AccountId
account

accountId
Holding
securityId
security
SecurityId
id
Security


… Without Violating Theory
…while remaining on
Account
firm theoretical id
account
ground. AccountId

accountId
Holding
securityId

SecurityId
security
id
Security


Properties Can Be Polymorphic
Properties are usually
Account
polymorphic… id
AccountId
account

accountId
Holding
securityId
security
SecurityId
id
Security


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


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


It Computes …
Account
id
Partition
AccountId
account
Compose accountId
Holding
collectListElementsFrom: [holdings]. securityId
groupedBy: [account]. security
…
extendBy: [ SecurityId
… id
!ofactor <- groupList total: […] Security
…
];


In Parallel …
Portfolio super
Account
Aggregate
Index id
AccountId
in0 in1 in2
Holding
accountId

securityId
security
SecurityId
Compose/Join id
Security


But All Of This Is Well Hidden …
All a user sees is a !lowerPct <- pctEq * 0.8; !upperPct <- … ;
conventional object select: [type isEquity].
oriented programming collectListElementsFrom: [holdings].
language. select: [pctEq >= ^my lowerPct
extendBy: [
!xref <- ^my holdings;
percentOfPort min: (^my xref at: security.
percentOfPort)
]
].
sortDown: [ofactor]
];


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.


Questioning Assumptions - Reprise
Entity based applications fit into a neat little
box.
That which an application sees and
manipulates is the way it really works.


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.


Where Are We?
commercially proven
solid theoretical underpinnings
unified, inherently parallel data base programming
language integration


And, Of Course …
Objects are records with byte codes on the side?

It Ain’t Necessarily So.


Objects arent records with byte codes on the side

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Objects arent records with byte codes on the side

Similar to Objects arent records with byte codes on the side (20)

Recently uploaded

Recently uploaded (20)

Objects arent records with byte codes on the side