Bryce wants to make the methodDictionary a table.

Post #99,482 by tuberculosis 4/30/03 1:29:41 PM 8/21/07 6:08:23 AM Reply	Bryce wants to make the methodDictionary a table. Its not a fundamentally different structure than any other home-grown object system, but he's pretty much into creating something like self but putting all the behavior as eval scripts in a table. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police Edited by tuberculosis Aug. 21, 2007, 06:08:23 AM EDT Bryce wants to make the methodDictionary a table. Its not a fundamentally different structure than any other home-grown object system, but he's pretty much into creating something like self but putting all the behavior as eval scripts in a table. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police Collapse All History
Post #99,516 by tablizer 4/30/03 5:08:19 PM Reply	relational model of OOP A basic OO structure: \n Table: Objects\n --------------\n Object_name\n Parent \n\n Table: Method_attributes\n -----------------------\n Object_name (foreign key to Objects table)\n Message_name (attribute or method name)\n Value_type (method, attribute, or pointer indicator)\n The_value (attribute value or algorithm)\n It could be made fancier, such as multiple inheritance, etc. ________________ oop.ismad.com
Post #99,519 by admin 4/30/03 5:32:04 PM Reply	Been there, done that, have the MI t-shirt. [link\|http://web.archive.org/web/20010718000433/w3.one.net/~jweirich/oostuff/foxpro.html\|yawn] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #99,705 by tablizer 5/1/03 5:14:35 PM Reply	monomorphism If you use tables to do OOP, you get long ugly code like that. The trick is to use tables to do table stuff, not OOP. In the real world, splitting entities into subtypes does not work very well: there are too many orthogonal and often equally valid ways to "divide" something. Thus, rather than make one factor the arbitrary king (division criteria) and demote the others, simply don't divide. You query to get as-need "divisions", not hard-wire them into your physical code structure. OO'ers are often too quick to force things into taxonomies, which upon philosophical inspection or hindsite are usually arbitrary or specific to a narrow use of the entity. This is what happens when you over emphasize use-cases or CRC cards, for one. ________________ oop.ismad.com
Post #99,709 by admin 5/1/03 5:27:13 PM Reply	Re: monomorphism First of all: way to miss the point. You mentioned that multiple inheritance could be added; I gave an example. Sheesh. In the real world, splitting entities into subtypes does not work very well: there are too many orthogonal and often equally valid ways to "divide" something. Then don't do that. We've been over this before. Subtyping is not the end-all be-all of OO design. And don't give me that "most people are taught inheritance only" crap. Their (and your) ignorance is a commentary on their education only, not on OO. Further exploration of this topic will be ignored, as We Have Been Over It Before. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #99,728 by tablizer 5/1/03 6:00:43 PM Reply	If you remove inheritance ...then OO is little more than bloated procedural, or a 60's style navigational database built from scratch. ________________ oop.ismad.com
Post #99,734 by admin 5/1/03 6:09:46 PM Reply	I didn't say remove it. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #100,076 by tablizer 5/3/03 1:24:15 AM Reply	Perhaps "ignore" is more appropriate ________________ oop.ismad.com
Post #100,101 by admin 5/3/03 8:45:12 AM Reply	I didn't say that either. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #100,079 by deSitter 5/3/03 1:32:34 AM Reply	Re: monomorphism This is actually interesting! By "table", you really mean "array" - and so what you want is efficient indexing. So look at APL. -drl
Post #100,206 by tablizer 5/4/03 3:08:18 AM Reply	APL is not the only way to get efficient indexing Machine efficiency is not the whole issue. Maybe check out: [link\|http://www.c2.com/cgi/wiki?CodeAvoidance\|http://www.c2.com/cgi/wiki?CodeAvoidance] ________________ oop.ismad.com
Post #100,217 by deSitter 5/4/03 9:14:25 AM Reply	Do you finally admit ..that OOP is a method - a particular cooridinate system? Then we can talk about your array-centric language, as another coordinate system. If you're so radical anyway, why don't you make something that fits naturally on a stack machine? -drl
Post #100,249 by tablizer 5/4/03 3:52:08 PM Reply	why? If you're so radical anyway I am not "radical". I get emails from people who have similar ideas all the time, and many shops I have worked at are heavy users of RDMBS. (True, they perhaps are more likely to hire/rent table-heads than average.) that OOP is a method - a particular cooridinate system....why don't you make something that fits naturally on a stack machine? Anything could probably be implemented as a stack and/or a coordinate system and/or gerbals on gears. Stanford students built a computer out of only tinkertoys. However, I am more concerned about an app developer's interface (as languages and/or tools), not compiler writing/implementing. ________________ oop.ismad.com
Post #100,334 by deSitter 5/5/03 10:09:10 AM Reply	Yes you are You're radical, because you are doing "root level" work (look up the word "radix"). You want to invoke new methods. So I ask again - do you admit that OOP is a technique, and not a theory? -drl
Post #100,380 by tablizer 5/5/03 3:33:00 PM Reply	radix is the "bucket sort" because you are doing "root level" work (look up the word "radix"). I am not implementing a sort algorithm. How the database does its lookups is hidden from the DB user. So I ask again - do you admit that OOP is a technique, and not a theory? The distinction is blurry. ________________ oop.ismad.com

Welcome to IWETHEY!