I don't understand why you mention "eval"

Post #156,986 by FuManChu 5/25/04 9:30:28 PM Reply	I don't understand why you mention "eval"
Post #157,002 by tablizer 5/26/04 1:27:26 AM Reply	re: I don't understand why you mention "eval" See: [link\|http://www.geocities.com/tablizer/prpats.htm\|http://www.geocities...blizer/prpats.htm] ________________ oop.ismad.com
Post #157,044 by FuManChu 5/26/04 10:57:29 AM Reply	I get it now. Emphases mine: Some OO fans say that putting expressions or code into tables is "doing OO without OOP". Rather than get caught up in chicken-or-egg terminology battles, let's just say that I prefer tables because of their 2-D nature as opposed to the 1-D nature of OO code. Placing code in collections pre-dates the birth of OOP (Simula-67) by roughly a decade, at least. OOP gets credit for using classes to do such, not collections. LISP pioneered many aspects of treating code and data in a similar fashion. Even without Eval or Execute, the p/r version is still better than the OO version in my opinion. I will grant that the OO approach offers a bit more potential compile-time checking, but not much else. (Perhaps sacrificing run-time changes/additions in the process.) Further, it seems more logical to use the same collections management approach for both program code AND data. Otherwise, you are duplicating effort (special IDE's), duplicating schema information, and increasing the learning curve. Collection handling should be factored into a single methodology regardless of whether it is code or data. LISP came closer to the right idea by treating code like data instead of data like code, which is what OO does wrong. Got it. Subjectivity wins again. I think from now on you're going to have to work very hard to convince anyone here that you don't prefer OO, albeit a twisted version.
Post #157,053 by tablizer 5/26/04 12:43:59 PM Reply	OO is just a (bad) reinvention of 60's databases with ...behavioral dispatching tacked on. ________________ oop.ismad.com
Post #157,057 by folkert 5/26/04 1:10:43 PM Reply	No. You are a proponent of OO programming. I just didn't see that you were so exotic in your methodologies. Come on Bryce don't make me taunt you, causing Ben to hate me MORE! You are a strong OO proponent. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* Give a man a match, he'll be warm for a minute. Set him on fire, he'll be warm for the rest of his life!
Post #157,085 by tablizer 5/26/04 4:17:57 PM Reply	The question that launched a thousand arguments I keep saying that OO reinvents databases in app code. Thus, are OO programs really databases or are databases with code really OO? This issue came up before but nobody could agree on a definition of OO in order to determine for once and for all. The biggest seperation between OO and TOP is that OO wants to use code (text) to make "records" (aka "objects/classes") and use pointer-hopping to navigate relationships (aka "navigational database") rather than relational algebra. Reduce dependence on text-code and pointer-based navigation, and TOP and OO would not be that much different. ________________ oop.ismad.com
Post #157,086 by FuManChu 5/26/04 4:21:36 PM Reply	That explains a lot Thus, are OO programs really databases or are databases with code really OO? Do you really believe this question has an answer?

Welcome to IWETHEY!