Re: [MUD-Dev] **sigh** OOP wars and defining RDBMS

[Jeff Kesselman <jeffk#tenetwork,com>]

At 08:39 AM 8/31/97 PST8PDT, Olawrote:
>THAT was the design rational for databases, historically.  You may of
>course use a database with only one "client" if you choose, for convinience
>or whatever.  They are however accessed in manner that is conceptually
>viewed as atomic execution of functions, where the database is consistent

Okay we are tallkign appels and orenges here and lets forget it.

Im talking the fudnemntals of RDBMS theory.  The afct that any data can be
organized into a set of linked tables and the software that derives from
that theory that allwos the storage of any data in a common format
organized for fast retireval on a secondary storage device..

You're talkign abotu teh development of a aprticualr kidn of applciation
based on that theory.

lets drop it.

>and other types of information.  And the fact remains, if you change your
>object-system (class-hierarchy if you like)  you need a wipe if the data
>stored in the internal structure is reflected on the secondary storage
>device. (which it will if you use straight persistence)

Right and if you use a RDBMS and store that structrue as DATA that can be
modified independantly then it is not stored as aprt of your data valeus
and no 
wipes are necessary.  I cant explain this any better.  Myabe Bransdon
(Gillespie) wh ohas worked on the inertnals of cold can explain it.
Otehrwise I suggest yo utry a little Smalltalk or Cold and jsut see for
yourself how it works.

>
>Anyway, if realtime information is no problem, why don't you just use
>plain core-dumping for saving your data between executions?? Tell me!
>Core-dumping would be the most efficient and easy way to do persistence,
>wouldn't it?

Beause it would by definition have al lthe proeprties you justy decribed,
which this apoproach does not.

>
>>>Anyway, for all practical purposes, I think C++ or other OO languages
>>>decending from ALGOL/SIMULA was implied here.  I care about control and
>>
>>Well, OO was really first fully developed as a cocmept with Smalltalk.
>
>Well, actually it was first developed with Simula in 1967. Explain what
>you mean by "fully".  I've had both of the authors of Simula as lecturers

Everythign is an object.  Function calsl do not exist. Parents are muteable
and   unknown and reached simply and  only by throwing the emssage back
onto tehc all tree.  Maybe what Im describing is "ful lencapsulatioN' as
muchas  anything but I dont think you have a true OOPL withotu ful
lencapsulation.

The thing it causes is a fundemental paradoigm shift in how you program.
Something C++ certainly does not. If C++ is like SIMULA then Ild have to
guess neoither does that language.

>Anyway, you cannot get away from the fact that ALGOL-type languages 
>(simula, pascal, c, c++, java) maps nicely onto the current von
>Neuman machine architectures, and in fact microprocessors are optimized
>towards such languages (+ fortran).  So for any practial purpose you'd
>want to go with an algol like language for any computationally intensive
>application.

Poitn of fact, there is always a tarde off between efficiency and
flexability.  For al lthe reasons yopu laid out I prefer flexability for a
MUD project.  Ild note that for the record, thet orer of langauegs yo
uspecified at least in terms of C++ to JAVA shows a general trend AWAY from
staticlky bound "maximally efficient" langauges and twoard such
felxability.  We have LOTS of cycels these days anmd more all the time.
Correctness of code and maintainabiltiy are fast becomign more important
then optimal coe efficiency.


JK
Jeff Kesselman
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net

-----BEGIN GEEK CODE BLOCK-----
     Version: 3.1
     GCS/CC/E/IT/MC d+(++)@ s: a C++++$ ULSC+++(++++)$ P++(+++)$ L++ 
     E--- W++$ N++$ o+ K--? w++(+++)$@>--- O+(++)>$ M+>$ !V PS++ PE+ 
     Y+ PGP- t+ 5+ X- R+(++)$>+++* tv+ b+>++ DI+++ !D G e++ h r+++ y+++
------END GEEK CODE BLOCK------ 

Speak Geek!
http://krypton.mankato.msus.edu/~hayden/geek.html