Objectives of lecture:
Interaction between programming and operating system
Prominent compiler specialist in the 1970s: "I don't know what langauge we will be programming in in 25 years, but I know they will call it FORTRAN". He was wrong, FORTRAN died (sort of). Languages: C won, because Unix won, because Unix was open, cheap, etc. C did not win because it was modular, easy to debug, etc. Unix did not win because it was consistent, easy to learn, etc. Did Unix really win? Microsoft seems to own the market at the moment... Hang on, the Linux open source world is chasing Microsoft... DOS won not on technical brilliance but due to connection to open architecture hardware; Windows won not due to technical brilliance, but by inheriting a large user base Active X and other Microsoft programming tricks (Visual Basic, COM) inherit this advantage (see law suit...) Is this the end of history? I doubt it... In retrospect, it will all seem obvious, but there are a lot of dead ends out there...
For a certain period, the "programming" done now was performed in "application languages", like SQL or AML (Arc Macro Language) or Avenue.
Arc/INFO up to version 7 was still mostly in FORTRAN, but not ArcView (kernel is C with some Object toolkit, then Avenue).
Arc/INFO finally had to cave in to the Open API world (adopting Microsoft's COM), (They took the document ode0298.pdf offline, perhaps they changed the story and are hiding the prior versions...) Now this is expressed as Arc 8 and ArcObjects (look at the ArcObjects tab inside the big pdf)...
Now that ESRI has abandoned (officially) their Avenue platform, the programming environment has shifted to Visual Basic (and such tools).
readable, structured, concise, efficient, documented and maintained... (Pick 2...)
Structured code is not simply removing GO TOs, it is choosing
the right modules.
ADA "packages" with hidden details and published interfaces
is actually the "clean" way to structure code (modularity
comes from the characteristics of OO from last time: encapsulation,
methods, messages...). C makes it hard to enforce rules of cleanliness.
Some distinctions among programming languages:
Old days- the basic primitives were:
You did the rest. (Calcomp plotter routines, Tektronix
PLOT-10 - drivers for Arc/INFO)
Usually you would begin to implement the facets of a modern graphics
interface:
World coordinates, "normalized space", and device coordinates
(drivers for each)
One example Graphics Kernel System (GKS) (see also, CORE; PHIGS;
CGI; X-windows)
Printers have their own graphics processors with different view
of resolution, using PostScript, HP page description language,
Adobe Page Description Format (.pdf), etc.
Each vendor developed a Graphical User Interface (Macintosh, Windows,
Windows-NT, OS-2, OpenWindows, NextStep (uses PostScript for primitives),
etc...) so now there are many many standards and flavors of standards...
At the bottom all of them support move and draw for lines plus
text and area fill (never enough points for mapping, though);
This is why Avenue had to be done separately (?) ArcObjects adopts
the Microsoft screen objects and interface wholesale...
In the card era, user interface began forcing the parameters
into specific columns of specific cards- "magic" decks
were nursed along, the basic mantra recapitulated
Free form input came along with terminals, though first there
was an era of closed end, computer lead dialog. Basic mode of
free format is sentences (imperative) with verbs and objects or
commands with "switches", modifiers, parameters... User
interface takes a lot of time to program.
Table driven language systems were replaced with pull-down menus
and dialog boxes
Plus ca change, plus c'est la meme chose...
A real standard becomes so obvious that no one would think to challenge it. Consider the Edison plug in the US 110 Volt distribution system. Yet, in other places, plugs are much less standardized (inside french houses there may be three standards...)
There is a move towards standards, not just for geographic DATA (and metadata) but for programming interfaces and "services". This may or may not come to fruition.
Everyone does objects, but some do objects more than others...
Smallworld (now GE Smallworld) has an object-oriented approach
and a number of white
papers to describe it. Their manifesto
from 1991 ; "Some
objectivity please", a white paper (undated...) from
about 1993.
Object-oriented is used in a number of distinct contexts. Some like Peter Batty of Smallworld have tried to make some coherence in the use of the term (objectivity paper). Batty recognizes the following meanings for GIS:
A solution in one of these isn't necessarily a solution in all.
Objects structured as instances of classes (with
some kind of inheritance structure); this approach is really about
Abstract Data Types where the programmer has a lot of flexibility
in creating new classes of objects. Inheritance is one way of
making generic structures operate, there are parameterized templates
that are more directly a programming strategy. (depends on platform,
etc.)
Methods and Messages: an object does not just have data,
it knows what to do with it, so there are some "methods"
associated with a class (like Draw...). Methods allow objects
to encapsulate their behavior, so that the outside needs only
to send a message to the object to make things happen (not to
muck around inside). This is good and bad. If you don't create
all the needed methods, you have to do some work-arounds...
Translating terms into COM and the ArcObjects world:
Lots of programming solutions end up using the OO mostly for
a pre-packaged interface toolkit, with the program behind still
written the old way. Method is hard to implement... OO is hard
to accomodate with huge memory models (databases).
databases are not identical to programming languages, while
programming has converted largely, the database world remains
dominated by the relational approach in the commercial sector.
See the OO Database System Manifesto: A consensus from academia
(6 academics' opinion):
8 rules that define "Object-oriented"
5 rules that make it a database management system
5 optional goodies that enhance an OODBMS
Much richer than Relational, so harder to implement. ESRI's SDE isn't really an OODBMS...
Study question: Why does relational technology
conflict with object technology?
The word object is used for a lot of purposes in describing cartographic data. In some cases, the word is simply a synonym for "vector", because you have distinct objects. However, this misses a lot of the point... Some people have made the following nuances:
"object-centered" (as opposed to geometry centered)
"object-based" (as opposed to sheet or tile-based)
Most technical works do not recognize how different the measurement frameworks are for isolated versus connected approaches. Thus, the use of the term "object" here simply confuses everyone...
point, line and area?
What about relationships?
Daniel Karnes
PhD 1995 Modeling and mapping new metaphors: Towards pluralistic
cartographies using object-oriented geographic information applications:
Or a dynamic
model of the land parcel network.
<diagrams><SmallTalk code>
Bottom line conclusion: one cannot start out saying a Point
"has" a coordinate. You should say that a point, when
requested, examines its internal methods and returns you a coordinate...
This is the real difference in a fully OO approach. Nobody does
this in the commercial sector. They still use primitives and do
not permit you to revise them...