Post #70,616
12/24/02 1:24:45 AM
12/24/02 1:29:14 AM
|
A relational definition of OOP
On wiki (c2.com) I posted this under ObjectsAreDictionaries:
This is one definition of "objects" or "object oriented programming". Note that no distinction between class and object is made here, as it is assumed to be a language-specific feature rather than part of the definition of ObjectOrientedProgramming.
This "dictionary" comparison roughly comes about as a combination of RobertMartin's "jump table" definition of OOP, and an observation that in dynamic OOP languages, objects and classes are basically dictionaries (AKA, associative arrays, hash tables) where the method name is the key, and the result is either an attribute value or algorithm (method code). In staticly-typed languages, you simply have a more complex key (method name plus parameter signature) and some access limitations or rules. Aside from "prototype" languages or techniques (which are still considered "inheritance" by most, but use a kind of mitosis {clone} approach), the one extra thing besides the dictionary is the "search path" to the parent(s). If the item is not found in the current dictionary (object), then the search path is checked for other dictionaries that contain the method/attribute (or message) name.
With this view, an object or class is the dictionary, and ObjectOrientedProgramming is the process of creating software using *combinations* of these dictionaries (with an inheritance path).
A relational view of this definition would look something like this:
Table: Objects
--------------
Object_name
Parent_path
Table: Method_attributes
-----------------------
Object_name (foriegn key to Objects table)
Message_name (attribute or method name)
Value_type (method or attribute)
The_value (Attribute value or algorithm)
(The Value_type and Parent_path are language-specific additions to the basic concept, but fairly common in practice. The Parent_path perhaps should also be a table in itself if multiple inheritance is supported. Otherwise, it is a recursive key.)
A relational definition of OOP? Doesn't that violate a prime-directive or something? :-)
________________
oop.ismad.com
Edited by tablizer
Dec. 24, 2002, 01:29:14 AM EST
|
Post #70,632
12/24/02 8:31:40 AM
|
It makes sense to me but also
object=definition as verb
the idea of objects verbs dictionarys etc are parts of a language ergo
Computer Science=language arts and a CS degree is not a science degree.
An EE is a science degree.
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #70,655
12/24/02 9:59:17 AM
|
Pretty much correct
At least in Smalltalk - the whole thing is dictionaries - a class is a method and variable dictionary, and an object is a variable dictionary with entry pointing back at its class. Thats how it works.
Very good Bryce, you are groking it bit by bit.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,752
12/25/02 1:08:35 AM
|
re: Pretty much correct
Well, if it is all pretty much a dictionary, then that is key to my complaint about OO. What is more flexible and open-ended: an app built with the full power of RDBMS, or one based on the connection of a bunch of dictionaries? What makes a better fundimental building block: a bunch of dictionaries hand-wired together, or something using the set- and table-based relational paradigm?
Larger OO apps pretty much hand-reinvent the rejected Network DBMS's of the 60's. OO is trying to revive a dead horse. OODBMS vendors kept running into similar problems that they already hashed out in the 1960's and 70's, where relational won over NDB's and HDB's (like IMS). Those who don't understand history are.....
________________
oop.ismad.com
|
Post #70,760
12/25/02 6:31:49 AM
|
The difference.
Well, if it is all pretty much a dictionary, then that is key to my complaint about OO. What is more flexible and open-ended: an app built with the full power of RDBMS, or one based on the connection of a bunch of dictionaries? What makes a better fundimental building block: a bunch of dictionaries hand-wired together, or something using the set- and table-based relational paradigm? The difference is threefold. First, the dictionaries are special purposed via the language's symbol tables. Secondly, they are created by the compile-time system and maintained for object instances by the run-time system. Secondly, there is a syntantic difference in utilising the paradigm in this particular way which often proves beneficial. IOW, it is a useful abstraction. Wade. "Ah. One of the difficult questions."
|
Post #70,823
12/25/02 5:13:53 PM
|
Re: The difference
The difference is threefold. First, the dictionaries are special purposed via the language's symbol tables. Secondly, they are created by the compile-time system and maintained for object instances by the run-time system. Secondly, there is a syntantic difference in utilising the paradigm in this particular way which often proves beneficial. IOW, it is a useful abstraction.
I couldn't get anything concrete out of this description. The "compile-time" reference seems kind of language-specific, for many OO languages have no compile-time (and we don't want yet another static-vs-dynamic debate breaking out). Examples would be helpful.
________________
oop.ismad.com
|
Post #70,866
12/26/02 12:19:52 AM
12/26/02 3:42:13 AM
|
Okay, I'll try again.
By "compile-time" I meant during the process of parsing and lexing the source code into something that could be considered executable, be it some sort of byte-code or real machine code. A lot of what are often considered scripting languages do this every time they run a program - Perl, for instance. However, in the following description I would prefer you think in the context of a C++ compiler as it has a more conventional compile cycle.
This process normally populates a number of symbol tables for various items: variables, functions, classes and objects. The intermediate representation of the code relies on these symbol tables to know what the data it points to is for, contains and is allowed to do. Thus, our first dictionary.
The second dictionary mapping takes place when we examine those symbol tables a little more closely. Classes with methods would effectively get their own symbol table* for their calls. Calls to those class methods would get replaced with a compact representation to that symbol table entry. We now have our second dictionary.
Now some of this information needs to stick around after the parsing and lexing is complete. Why is that? Well, the first answer is idiotically simple: external functions need to be link-edited by name. :-) Slightly more advanced we might have functions of our own that need to be made visible - again by name - to other compiled modules. A third dictionary, though not one pertaining directly to OO.
However, there is some remaining symbol table information required for runtime behaviour. And that is for a technique called dynamic dispatch. From a dictionary point of view, dynamic dispatch says that if a function call can't find its function in the dictionary attached to it's object, it can look in the dictionary attached to its parent object. This information is taken from our second dictionary type to create a fourth.
At this point we come to the point I was originally making. All of these dictionaries are intended for performing a fairly specific function of mapping names to information. They generally function fairly invisibly and scale up and down usually more than enough to suit their specific purpose. At no point are they general purpose dictionaries. Instead, the fact they are really dictionaries - and, in fact, that there are quite a number of them - is abstracted beneath the slightly more specific role they perform. Like symbol table lookup. Or dynamic dispatch.
Thinking of polymorphism, inheritance, dynamic dispatch and other aspects of object-oriented or object-aware programming as dictionary-based logic is an interesting academic exercise, but IMHO reducing the former to the latter is a distinct step backwards.
Wade.
* Whether or not this really happens is actually an implementation detail and is unimportant to this discussion.
Appendix.
I should re-iterate that I'm a fan of clever decision trees in my logic. Handing a function pointer to a piece of code to change its behaviour I find preferable to coding in a huge switch() statement. Code that can do wildly different yet oddly similar tasks based on what its initial data is appeals strongly to me. Taking advantage of object inheritance and programmable code in the parent code is one such powerful tool. It makes my code smaller and smarter.
Edit: Corrected a noun's state in the footnote to reflect what I originally meant to type. Bryce didn't even notice...
"Ah. One of the difficult questions."
Edited by static
Dec. 26, 2002, 03:42:13 AM EST
|
Post #70,887
12/26/02 2:17:20 AM
|
re: Okay, I'll try again.
I should re-iterate that I'm a fan of clever decision trees in my logic.
Because they better map to the external world, or your particular mind?
its behaviour I find preferable to coding in a huge switch() statement.
A huge switch statement is sometimes a sign that a Control Table is needed. You should have anticipated I would say that. I guess I should troll here more often to keep you guys fresh.
It makes my code smaller and smarter.
I'll beleive it when I see it. I don't get why people like OO. I see no magic anywhere. The simplicity and beauty of shape, animal, stack, and device-driver examples just does not project into real world projects. It is like it is optimized for another universe.
________________
oop.ismad.com
|
Post #70,894
12/26/02 3:39:56 AM
|
Go troll elsewhere. (new thread)
Created as new thread #70893 titled [link|/forums/render/content/show?contentid=70893|Go troll elsewhere.]
"Ah. One of the difficult questions."
|
Post #70,771
12/25/02 8:29:46 AM
|
Its whats in the dictionaries that is interesting
Which is both data *and* behavior.
If you look at it from a purely data perspective, then yes, its got quite a lot in commone with hierarchical databases.
The flip side though is how behavior is implemented. This is the interesting bit - polymorphism is a wonderful thing that enables amazingly complex behaviors without writing code of amazing complexity.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,777
12/25/02 10:26:01 AM
|
Re: Its whats in the dictionaries that is interesting
I may be out of my gourd, but when you talk about these things I keep thinking of FORTH, which is very low level - hardly any convenience features. The code is extremely simple on one sense - there are primitives coded in very optimized assembler, and then words are just lists of pointers to the primitives - so a program is just long list of addresses to the primitives combined with proper preparation of the stack. On the other hand, words can be created with a dynamic runtime behavior (CREATE DOES>) so very complex things are easy to model (this is why it's a great realtime environment). See here for how code and data get "objectified" in the real world:
[link|http://www.tinyboot.com/man/crdoes.html|http://www.tinyboot.com/man/crdoes.html]
Tinyboot: [link|http://www.tinyboot.com/|http://www.tinyboot.com/]
Note that the way FORTH does this is by patching memory - it's brutal and effective. There is something deep there...
When I claimed to the FORTH people that "Object FORTH" was dumb because it was alreadly objectified, they scoffed :)
-drl
|
Post #70,834
12/25/02 6:33:38 PM
|
Its very similar
"The code is extremely simple on one sense - there are primitives coded in very optimized assembler, and then words are just lists of pointers to the primitives - so a program is just long list of addresses to the primitives combined with proper preparation of the stack. On the other hand, words can be created with a dynamic runtime behavior (CREATE DOES>) so very complex things are easy to model (this is why it's a great realtime environment)."
Yep. Smalltalks work somewhat like this - starting low level and aggregating upwards. But Smalltalk works on virtual hardware and the memory itself is an object with behaviors for persistence, compaction, garbage collection, etc.
I think Smalltalk adds higher organizing principles of classes on top of this low level stuff - but this is all implemented in Smalltalk itself and could be implemented in forth - IOW, you don't need to change forth to implement OO in forth - just build the appropriate infrastructure in forth itself.
It doesn't seem like that infrastructure is commonly built though.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,825
12/25/02 5:23:27 PM
|
marrying data and behavior
If you look at it from a purely data perspective, then yes, its got quite a lot in commone with hierarchical [and network] databases.
But I tend to find that the pattern of the data usage and differences does not really match the pattern of the behavior. They are too dissimilar kinds of things to try to paste together on the same taxonomies or code shapes. But tighter integration is possible to add to TOP, just not very useful in practice.
The flip side though is how behavior is implemented. This is the interesting bit - polymorphism is a wonderful thing that enables amazingly complex behaviors without writing code of amazing complexity.
I will believe it when I see it. OO turns simple things into complex things in my observation. For example, multiple dispatching. A table perspective of MD is dirt simple IMO, but OO twists it into cross-referency spahgetti code.
________________
oop.ismad.com
|
Post #70,835
12/25/02 6:36:37 PM
|
Re: marrying data and behavior
"For example, multiple dispatching. A table perspective of MD is dirt simple IMO"
As I recall, you liked to use eval to put little routines into fields of some tables, what you called control tables. Remind me how this works with an example.
Because I think we might just maybe be on the verge of reconciling the views here.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,888
12/26/02 2:22:41 AM
|
Re: marrying data and behavior
[re: Multi-dispatch] As I recall, you liked to use eval to put little routines into fields of some tables, what you called control tables. Remind me how this works with an example.
See: [link|http://geocities.com/tablizer/prpats.htm#dispatch|http://geocities.com...pats.htm#dispatch]
________________
oop.ismad.com
|
Post #70,915
12/26/02 11:01:14 AM
|
Got it
Look your control tables are just replicating what the OO languages do for you automatically. Also, your tables are sort of instance based. If you fully normalized the actions into tables you'd have something like a class method dictionary.
So its the same - only you do it in the database the hard way and OO developers have languages that take care of the grunt work automatically and leave the behavior in code libraries.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #70,919
12/26/02 11:43:47 AM
|
you are not weighing the whole kitten kabootal
Look your control tables are just replicating what the OO languages do for you automatically.
You mean:
eval(rs.action)
instead of
thing.action()
A very minor thing to fuss about. Viewing, typing, filtering, etc. the same info in tables is 10-times easier for me. The same thing in code is like the difference between reading a bus schedule on a browser (rendered) versus reading it as HTML code (with TABLE and TD-like tags).
If you fully normalized the actions into tables you'd have something like a class method dictionary.
What specificly is un-normalized? I know how to normalize tables. I can do it in my sleep.
only you do it in the database the hard way and OO developers have languages that take care of the grunt work automatically and leave the behavior in code libraries.
Tablizing it is actually *less* code because you don't repeat the equivalent of cell labels over and over. The "packaging" of the cell contents is not repeated over and over because the database factors that into its internal field dictionary. Plus you can get different views by issuing queries or dragging columns without upsetting any code. Your view is not limited to that envisiond by the original programmer. You can transcend them.
All it is costing me is an "Eval", and saving dozens of lines of packaging code in return. Seems like a bargain to me.
________________
oop.ismad.com
|
Post #71,052
12/27/02 2:42:14 AM
|
Kitten Kabootal?? Is that some stripper you know?
It's "kit and caboodle", Bryce.
What is your version of the lyrics to the "Flintstones" theme?
-drl
|
Post #71,058
12/27/02 3:58:27 AM
|
Don't I wish :-)
________________
oop.ismad.com
|
Post #71,072
12/27/02 10:30:01 AM
|
I know her! great smile and a grinning kabootal!
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
You think that you can trust the government to look after your rights? ask an Indian
|
Post #71,435
12/30/02 7:49:04 AM
|
Sure I am - but you're not
From your own site you use this example: \r\nModem \r\n \r\n\r\n| OS | \r\nModel | \r\nSpeed_Low | \r\nSpeed_High | \r\ndial | \r\nsend | \r\nrecv | \r\nhangup | \r\n \r\n\r\n| UNIX | \r\nHayes 20a | \r\n1200 | \r\n9600 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| UNIX | \r\nHayes 20a | \r\n14000 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Win-9x | \r\nHayes 20a | \r\n1200 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| UNIX | \r\nUSR Z20 | \r\n300 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n1200 | \r\n2400 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n4800 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Mac | \r\nKLM 10 | \r\n1200 | \r\n52000 | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n[implement.] | \r\n \r\n\r\n| Etc.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n.... | \r\n \r\n \r\nYeah fine. OK, this is what we would call an instance based approach. You have polymorphism. This is really good. And it is very OO. Because you have information hiding. You have an abstract interface called modem. It responds to dial, send recv, hangup. Its exactly the same as if you had said in Java:\r\n \r\npublic interface Modem\r\n{\r\n public void dial();\r\n public void send();\r\n public void recv();\r\n public void hangup();\r\n}\r\n\r\nIOW, you can take any modem and say something like modem.dial (or eval (modem.dial) its the same right?).\r\n \r\nSo this is actually a very cool thing you've done and I see why you like it. Its analagous to what the IOCTL type stuff on Unix does - where files and sockets respond to the same interfaces via function lookup tables in C. Its still just a dispatch table. \r\n \r\nIncidentally - a row in this table isn't any different than a dictionary. And a cursor in this table isn't any different than an iterator on a list of rows (which are dictionaries key'd by column name). But I digress.\r\n \r\nIf you look at the data in this table, you begin to see that there is likely to be a bunch of duplicated code. I'll bet send and recv are the same regardless of modem speed. Furthermore, a lot of modems are Hayes compatible and use the same commands. There are definitely different commands for setting connect speed otoh, but hangup is the same pretty much for all Hayes compatibles.\r\n \r\nSo maybe its worth it to normalize this and move all the common methods to a table so you can cut down on duplicate storage. \r\n \r\nModem \r\n \r\n\r\n| OS | \r\nModel | \r\nSpeed_Low | \r\nSpeed_High | \r\nIsA | \r\n \r\n\r\n\r\n| UNIX | \r\nHayes 20a | \r\n1200 | \r\n9600 | \r\n\r\nA | \r\n \r\n\r\n\r\n| UNIX | \r\nHayes 20a | \r\n14000 | \r\n52000 | \r\nA | \r\n \r\n\r\n\r\n| Win-9x | \r\nHayes 20a | \r\n1200 | \r\n52000 | \r\n\r\nA | \r\n \r\n\r\n| UNIX | \r\nUSR Z20 | \r\n300 | \r\n52000 | \r\n\r\nA | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n1200 | \r\n2400 | \r\n\r\nA | \r\n \r\n\r\n| Win-9x | \r\nUSR Z20 | \r\n4800 | \r\n52000 | \r\n\r\nA | \r\n \r\n\r\n| Mac | \r\nKLM 10 | \r\n1200 | \r\n52000 | \r\n\r\nA | \r\n \r\n \r\n \r\nModem Implementation Table \r\n \r\n\r\n| type | \r\ndial | \r\nsend | \r\nrecv | \r\nhangup | \r\n \r\n \r\n\r\nYou still get some duplication here if every modem uses the same hangup - but if two modems use the same code regardless you don't duplicate the whole set of procedures. So its a little better but not great.\r\n \r\nIf instead you flip it over and create an implementation table,\r\n \r\nImplementations \r\n \r\n| id | name | implementation |
|---|
\r\n \r\n\r\nthen create a definition table for grouping the implementations\r\n \r\nThings \r\n \r\n\r\nand a join table for many to many \r\n\r\nThingImplementations \r\n \r\n| ThingId | ImplementationId |
|---|
\r\n \r\n\r\nYou can arrange things so there is exactly no duplication of implementation scripts anywhere in your database.\r\n \r\nNow you have something like this:\r\n \r\nModemData \r\n \r\n\r\n| OS | \r\nModel | \r\nSpeed_Low | \r\nSpeed_High | \r\nThingId | \r\n \r\n\r\n| UNIX | \r\nHayes 20a | \r\n1200 | \r\n9600 | \r\nA | \r\n \r\n \r\n \r\nThings \r\n \r\n| id | name |
|---|
\r\n| A | HayesUnixModem | \r\n \r\n \r\nImplementations \r\n \r\n| id | name | implementation |
|---|
\r\n| 1 | dial | [implementation] | \r\n| 2 | send | [implementation] | \r\n| 3 | recv | [implementation] | \r\n| 4 | hangup | [implementation] | \r\n \r\n \r\nThingImplementations \r\n \r\n| ThingId | ImplementationId |
|---|
\r\n| A | 1 | \r\n| A | 2 | \r\n| A | 3 | \r\n| A | 4 | \r\n \r\n\r\nAnd to get modem behavior - you join ThingId with Thing.id through ThingImplementation and get the Implementations. Full normalization with no wasted space. Of course, its expensive to go to the database this often - so you'll probably want to read the Implementation tables and Thing defininition tables into memory and just keep them there, like you do with reference tables of code values.\r\n \r\nThere's one other thing thats potentially a bit of a drag. Defining a new Thing is maybe a lot of work - so we add a ParentID to Thing and aggregate methods by dragging in the Thing and all its parent scripts as well. When two scripts have the same name, we make the child thing's win. This way, you always define a new thing in terms of an old thing. This results in the potentially expensive self-join but guarantees minimal space expense if there's any similarity at all among things.\r\n \r\nOnce you get to this point - you've completely reinvented the OO runtime system in your database. \r\n \r\nSo your system, through normalization and evolution, will likely evolve into an OO system. You've got a good start on one.\r\n\r\n I am out of the country for the duration of the Bush administration.\r\nPlease leave a message and I'll get back to you when democracy returns.
|
Post #71,478
12/30/02 10:44:45 AM
|
Wow! If this woun't get through, nothing can.
My hat is off to you, Sir. Most lucid explanation ever.
--
We have only 2 things to worry about: That
things will never get back to normal, and that they already have.
|
Post #71,547
12/30/02 4:44:33 PM
12/30/02 6:09:32 PM
|
LISP - Lists + Relational
Yeah fine. OK, this is what we would call an instance based approach. You have polymorphism. This is really good. And it is very OO.
In that case LISP invented "polymorphism" because it pioneered the idea of "code in data structures". TOP is simply an extension of the idea of LISP's list into relational tables. IOW, "relational LISP" instead of the older "list-based LISP". The data structures have simply grown up.
Full normalization with no wasted space.
Most existing relational implementations don't use fixed-cell allocations, thus there is little or no "wasted space" for empty cells. The wasted space concerns are based on outdated technology.
Of course, its expensive to go to the database this often......you'll probably want to read the Implementation tables and Thing defininition tables into memory and just keep them there
Database != Slow
I would note that most XBase implementations from about 1992 on used caching of some sort so that smaller tables *were* in RAM. (I am sure the new stuff does it also, but harder to directly varify.)
Besides, such tables may be used for code generation if including a table engine is not practical (such as embedded systems). IOW, it can potentially be used to manage the source code rather than be used "live". Plus, I don't see a need to have lots and lots of repeated lookups anyhow.
There's one other thing thats potentially a bit of a drag. Defining a new Thing is maybe a lot of work - so we add a ParentID to Thing and aggregate methods by dragging in the Thing and all its parent scripts as well. When two scripts have the same name, we make the child thing's win. This way, you always define a new thing in terms of an old thing.
What you already presented already has plenty of indirection. I don't see why we need this also. Besides non-trivial "inheritance" is best set-based instead of tree-based. The real world changes in a graph-like fashion, not trees.
To share some implementation, a simpler, but slightly less flexible approach could have a schema like:
Table: ModemDrivers
-------------------
ModemID (or perhaps DriverID)
OS
Model
SpeedLow
SpeedHigh
Dial
Send
Recv
Hangup
DefaultID
This is pretty much the original table plan with the added DefaultID and ModemID (to supply a unique reference). The Default ID could point to either another table of defaults, or point to another record within the same table. It would use the default implementation if a given implementation cell is blank. Yes, I know, it would then be "tablized inheritance", but that is the way I like my inheritance.
I am perfectly aware of the similarities between OO and Control Tables. The bottom line is that it is easier to manage such stuff in tables than in programming code. You can see patterns in tables easier than in code. Part of the reason for this is tables allow you to eye the info by both row and column at the same time. A class cannot give you this. It is like the difference between looking at an HTML table (made with "table" tag) rendered in a browser versus the raw HTML code. Classes are like the latter.
Second, one can issue queries against such table(s) to filter and project one's view to customize it for a particular need. Relational has pretty much proven superior WRT queries compared to the network-DB-like model of OO classes or a bunch of grep-like unix/perl utils. (At the very least, grep-like approaches don't easily scale up to billion+ records and multiple users, and nobody wants to learn nor switch between two query approaches depending on the size of the collections.)
Also, the "inheritence" can be set-based or made more advanced than mere OO trees. Multiple inheritance (set-like in some ways) gets really messy for such, and is still limited. For example, the "share pattern" for say the Hangup operation may not match that of the Send operation. Sure, with enough class indirection such could be obtained, but I would rather manage a bunch of cross-references using tables instead of application programming code.
Further, since my dispatching is somewhat self-implemented, I could assign priorities to default lookups so that if a given default driver is not found, then it looks for the next largest in rank. OO pretty much supplies you with "dumb" inheritance that requires a Meyerian Discontinuity Fault (big-ass overhaul) to make the transition to such "fuzzy inheritance". On that same webpage, you can see my "UI event table" that has event priorities/sequences. I invite you to show how one would manage such in OOP. Who knows, they may even name a GOF pattern after you. (Yes, I agree it is probably possible, just not disirable.)
In other words, I can get sophisticated dispatching simply by adding to what I already have.
Incidentally - a row in this table isn't any different than a dictionary.
Relational requires that the full set of (possible) columns is known for a given table. This allows sophisticated operations and optimization. (I don't know if there is an equivalent to relational theory for per-row columns. This generally seems to hark back to the fallen Network Databases of the 60's with their tangled navigation webs. Nobody found a way to "purify" them.)
Summary of advantages:
1. Row-and-column view is more concise and makes it easier to notice patterns. (At least for my eyes.)
2. Relational query ability allows me to get just about any view I want. Joins, filters, etc.
3. I can incrementally obtain sophisticated dispatching, such as set-based dispatching and priority ranking.
If it was small and unchanging, then OOP inheritance may be just fine. Then again if it is small and unchanging, then so would a case/switch statement (except for stupid languages that need a Break clause).
Thank you for your response and the effort you put into it. I appreciate it.
________________
oop.ismad.com
Edited by tablizer
Dec. 30, 2002, 06:09:32 PM EST
|
Post #71,600
12/30/02 8:15:27 PM
12/30/02 8:50:07 PM
|
Gets you Smalltalk
In that case LISP invented "polymorphism" because it pioneered the idea of "code in data structures".
Maybe, can't say. I suspect you are right. I know that LISP and Smalltalk were like Yin and Yang influencing each other - CLOS was inspired by Smalltalk who's VM, GC, and code as data were inspired by LISP and on and on...
Most existing relational implementations don't use fixed-cell allocations, thus there is little or no "wasted space" for empty cells.
I'm not talking about wasted space for empty cells - I'm talking about it for duplicate copies of implementation rather than using inheritance. If every record in your modem table uses the same hangup routine, then you have redundant data.
Database != Slow
Compared to memory - there's a factor of several orders of magnitude.
What you already presented already has plenty of indirection. I don't see why we need this also. Besides non-trivial "inheritance" is best set-based instead of tree-based. The real world changes in a graph-like fashion, not trees.
I agree it complicates the runtime model - but it simplifies the conceptual model by allowing for classification. You can say "this is the same as that except for these". Telephone switch programming is crazy with this technique for both data compression reasons and UI ease of use (you don't want to enter every single setting for every single phone number individually - you'd be at it for years). Besides, trees are graphs.
The bottom line is that it is easier to manage such stuff in tables than in programming code. You can see patterns in tables easier than in code. Part of the reason for this is tables allow you to eye the info by both row and column at the same time. A class cannot give you this. It is like the difference between looking at an HTML table (made with "table" tag) rendered in a browser versus the raw HTML code. Classes are like the latter.
No, its the other way around. You're writing the indirection on an ad hoc basis. The OO language compilers systematizes (if thats a word) the approach and hides the complexity leaving you with (hopefully) the essentials of your design minus the ugly dispatch tables that make it work. You're doing the same thing that they do, in a less efficient and manual manner. It amounts to preferring assembler over C.
C helps you write structured logic, assembler doesn't prevent it, but it doesn't help much either.
Anyhow, I'm convinced you do understand it, you just don't like it.
Whatever, mission accomplished.
Now we never have to bring this topic up again. :-)
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,601
12/30/02 8:19:39 PM
|
Thanks! 1 topic down, Googolplex-1 to go. :-)
|
Post #71,870
1/1/03 3:37:08 PM
|
For Bryce, this is pretty much the only topic he discusses
over and over and over....
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #71,895
1/1/03 5:44:13 PM
1/1/03 5:49:31 PM
|
That is not true
I have been known to also rant on HTML P-tags, Remote GUI's (SCGUI), SQL (The COBOL of query languages), alleged cop racial conspiracies, arbitrariness of English, and lost hamsters.
________________
oop.ismad.com
Edited by tablizer
Jan. 1, 2003, 05:47:50 PM EST
Edited by tablizer
Jan. 1, 2003, 05:49:31 PM EST
|
Post #71,937
1/1/03 10:18:51 PM
|
Not to mention sheet music conventions/annotations. :)
Alex
"No man's life, liberty, or property are safe while the legislature is in session."\t-- Mark Twain
|
Post #71,967
1/2/03 5:14:45 AM
|
Woah - sheet music - I haven't seen that stuff in years...
I used to play on the Albuquerque bar circuit.
Top 40 you have to learn off the radio. The sheet music is 1) always simplified and 2) comes out months after the tune has peaked if it comes out at all.
Standard answer to question "can you sight read" was "why - somebody write something down"?
Actually I tried to learn to read several times. But my ears are so good that as soon as I've heard it I just play it - bypassing the painful mental act of visual decoding and translation.
I don't suppose I'll ever learn...(sigh).
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #72,053
1/2/03 1:17:41 PM
|
Playing by ear
Playing by ear gives you at least one thing the sheet music cannot: The feel of the song.
While I can read sheet music (for some values of read), I do much better when I've got a copy of the song to listen to because I can get more of feel for the groove of the song than is possible using the sheet music alone.
-----
Steve
|
Post #72,098
1/2/03 6:22:04 PM
|
ObAol MeToo (tm)
I always had (and still have) trouble sight-reading because I play by ear. Back in the days when I was a kiddy and still having piano lessons, when I given a new song I go and program it into my TI 99/4a (the speed at which I could type in a CALL SOUND statement...) so I could figure out what it sounds like.
Once I started doing that it was heaps easier to learn the songs I had to play. Not at all helpful WRT my learning how to sight-read, though...
John. Busy lad.
|
Post #72,129
1/2/03 8:58:55 PM
|
Re: ObAol MeToo (tm)
Do you mean "sight read" or "read music"? I can read piano music and more or less hear it - but I can't "sight read" as I understand it for a damn.
-drl
|
Post #72,137
1/2/03 10:15:55 PM
|
I can read music, I'm just really slow at it.
John. Busy lad.
|
Post #72,170
1/3/03 4:53:00 AM
1/4/03 4:41:59 AM
|
That's really interesting.
Because I have an ear for the feel of music, but when playing, I still prefer to play from chord charts. OTOH, melody lines I can play at speed from manuscript, though hearing it first is Very Helpful. :-)
Then too, I've played from a chord chart cold (in a church band) and the song leader suspected but couldn't be sure that I hadn't played that song before.
Wade.
Microsoft are clearly boiling the frogs.
Edited by static
Jan. 4, 2003, 04:41:59 AM EST
|
Post #72,219
1/3/03 10:55:19 AM
|
Speed-reader here
Though most musicians would look at drum or percussion music and lose their minds. If you're talking percussion (not counting marimba and other keyboard-like instruments) the notes will generally be all on one line. Or rather each line is a completely different instrument. Often each instrument will have a different-shaped note head.
Then there's the stuff they give the guy playing the drum set in a pop/jazz/rock etc. band. It's frequently so over-written it's nearly unplayable. I usually just asked for the lead sheet (for standards, the kind with a melody and chord progression) or a copy of the first trumpet part. Basically give me the melody line and let me figure out what to do with it.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #72,467
1/4/03 1:13:52 PM
|
You're a drummer? Cool!
-drl
|
Post #72,624
1/5/03 2:11:58 AM
|
I use chord charts a lot
I make chord charts from sheet music all the time. I hate trying to turn pages in the midst of a song. I try to memorize as much as I can, but we do so many different songs, and a different set every week.
-----
Steve
|
Post #72,214
1/3/03 10:31:13 AM
|
Same here.
I can't play for shit from music. I end up memorizing the song more or less before I can play it well.
I can play melodies by ear after hearing them once, if I'm paying attention.
My son is learning to sight read quite well, thankfully. It's a useful skill to have in addition to playing by ear.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #72,659
1/5/03 11:47:43 AM
|
Todd, Steve, guys - just a well-meaning tip:
This kind of thing is exactly what the "As New Topic in" check-box is for.
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #72,661
1/5/03 11:51:53 AM
|
CRC, Just a Well Meaning Tip..
"As New Topic" is annoying as hell and more or less ruins the flow of a forum, unless (ab)used as a flame retardant. Who cares if side issues come up? When you are having a beer with your buddies, do you move to a new table when the conversation changes?
-drl
|
Post #72,662
1/5/03 11:55:45 AM
|
What's annoying as Hell is pompous know-it-alls, and...
...the fact that I apparently missed checking "As New Topic in" on my previous posting.
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #72,747
1/5/03 6:26:30 PM
|
Bar table load times aren't affected by size of past chat
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #72,755
1/5/03 6:44:30 PM
|
That's the legitimate use
Somehow it seemed more civilized to say "let's move to here".
-drl
|
Post #72,777
1/5/03 7:19:15 PM
|
Naah, you're missing the REAL use:
Seamlessly "moving" the discussion to "tables" where people who might be *very interested* are more likely to be "sitting": What about all the people here who might have a burning inteerest in music-sheet-reading, but never wander into the Programming forum? T'would have been nice to *them* to dump this in Open, or the Water Cooler, or something (Entertainment, perhaps?).
Especially since you *don't* have the hassle, here, of everybody having to physically get up, bring their beers (and other assorted beverages) with them, notifying the waitress of the move if they're running a tab, seeing if there's room at the other "table" to squeeze down their butts, etc, etc.
But, fuck, anyone *else's* convenience but *yours* isn't something you care all that much about, is it?
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #72,779
1/5/03 7:22:06 PM
|
Re: Naah, you're missing the REAL use:
Just stating an impression, CRC. No biggie. It's wonderful work.
-drl
|
Post #72,785
1/5/03 7:38:47 PM
|
OK, that last point is one we can agree on, at least! :-)
|
Post #73,023
1/6/03 5:56:25 PM
|
If I had any idea this would be so hot
I would have started a new topic.
Who knew?
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #73,119
1/7/03 2:01:02 AM
|
Well meaning tip
Don't run with scissors. ;^)
Like Todd said woulda, prolly shoulda, but dinna.
-----
Steve
|
Post #73,145
1/7/03 9:14:04 AM
|
Long as you knew you "prolly shoulda", that's all I wanted.
|
Post #71,679
12/31/02 3:53:20 AM
|
But I get juiced-up dispatching, et al.
[Database != Slow] Compared to memory - there's a factor of several orders of magnitude.
Databases don't have to run from disk. For dedicated uses, I agree that some hand-built structure is probably faster. However, when you start looking at the same data from different perspectives (different joins, different keys, etc.), then the DB approach will start to shine. DB's are decathlon athletes, not specific event athletes. (BTW, Oracle is designing a RAM-only RDBMS I hear.)
Telephone switch programming is crazy with this technique for both data compression reasons and UI ease of use (you don't want to enter every single setting for every single phone number individually - you'd be at it for years).
I did not propose duplication. We would have to study the actual patterns to see what underlying structure and repetition pattern is really there. IMO, too many developers "see" trees where there is not really clean trees. Months or years later one often has to deal with refactoring a lot of code and other shuffling to compensate. I once had to build a special "3D rollup" accounts receivable turnaround tracking and reporting system. The structure looked like a classic roll-up tree at first, but I eventually gave up on the tree idea and found sets worked much better. I admit that it takes more training to get the users (accountants in this case) to understand sets, but lucky I had a smart user for that one. She picked it up in a snap. One is not always that lucky.
I will admit that for many humans trees are easier to grok, but they just don't reflect the messiness of the real world that well.
Besides, trees are graphs.
Yes, but the reverse is *not* true, and that is the problem. Sets are more general-purpose than trees. You can build trees with sets, but it is much trickier to build non-tree sets with trees. (Did I say that right?) IOW, sets can serve as trees much easier than trees can serve as sets. I say, go with the general-purpose tool rather than marry your design to trees.
No, its the other way around. You're writing the indirection on an ad hoc basis. The OO language compilers systematizes (if thats a word) the approach and hides the complexity leaving you with (hopefully) the essentials of your design minus the ugly dispatch tables that make it work. You're doing the same thing that they do, in a less efficient and manual manner. It amounts to preferring assembler over C.
I am sorry, but I just don't see this. Again, we would probably have to look at actual patterns of repetition and relationships to see what the ideal approach would be. Besides, the "trick" is to farm off the maintenance of such relationships to an operator or intern so that a programmer does not have to deal with actual data entry of such info. Being in tables we "inherit" off-the-shelf Db features like persistence, joins, multi-user-handling, report writers, RAD screen builders, query languages, table browsers, etc etc etc. How is that for "automatic"?
I will agree that my approach may require a little extra "manual dispatch" programming that OO would take care of IF trees were the best sharing shape, but my approach also allows one to use more "juiced-up" dispatching techniques if needed, without major code overhauls. I have seen trees run out of gas at least twice. Even in the off chance repetition patterns stayed tree-shaped, they are still easier to sift and view as tables. The dispatching code only need be written once, but the data (including code references) has to be maintained for a long time. Still a bargain in my book.
It is the classic tradeoff between a dedicated niche tool versus a general purpose tool. TOP dispatching is more general purpose, and thus will be a bit more costlier if the need tends to be just one thing. If you only use the cork-screw in your swiss army knife, then you might as well just buy a cork-screw. But the world is usually not tree-shaped in my observation.
Thus, add juiced-up dispatching ability to persistence, joins, multi-user-handling, report writers, RAD screen builders, query languages, table browsers, etc. I am not going to give all those up to save 1 line of code per 500 lines.
________________
oop.ismad.com
|
Post #71,617
12/30/02 9:59:33 PM
|
Re: LISP - Lists + Relational
Bryce, you justify my confidence in you!
-drl
|
Post #71,031
12/26/02 10:43:11 PM
|
re: Pretty much correct
Ok, who let you on the Wiki?
Larger OO apps pretty much hand-reinvent the rejected Network DBMS's of the 60's. OO is trying to revive a dead horse. OODBMS vendors kept running into similar problems that they already hashed out in the 1960's and 70's, where relational won over NDB's and HDB's (like IMS). Those who don't understand history are.....
And those who don't understand basic comp sci principles are...
Databases hold data. Programs written in procedural or OO manipulate that data. OO is not trying to reinvent a database any more than a procedural is trying to reinvent a database.
<sigh>
Regards,
John Urberg
|
Post #71,032
12/26/02 11:01:21 PM
12/26/02 11:33:32 PM
|
"Data" is whatever you make it
Databases hold data. Programs written in procedural or OO manipulate that data.
One man's data is another man's algorithm. It does not make sense to have your "noun model" be both defined in code and defined in the DB. It has to be either one place or another, either that violate OnceAndOnlyOnce.
BTW, does Static's reply make any sense to you? I couldn't "parse" it, and he got upset at me for that.
BTW2, Chris Date, author of the very popular database texbook, tends to share a similar opinion that you can put whatever you want to in table cells. He also complains about the lack of rigor in the OO field. You can ignore me because I am a loser, but not Chris.
________________
oop.ismad.com
Edited by tablizer
Dec. 26, 2002, 11:07:41 PM EST
Edited by tablizer
Dec. 26, 2002, 11:33:32 PM EST
|
Post #71,100
12/27/02 3:00:18 PM
|
Re: "Data" is whatever you make it
It does not make sense to have your "noun model" be both defined in code and defined in the DB. It has to be either one place or another, either that violate OnceAndOnlyOnce.
That's downright silly. If my "noun model" is originally defined in ER/Win, I'm violating the OnceAndOnlyOnce principle by using it in the database also?
BTW, does Static's reply make any sense to you? I couldn't "parse" it, and he got upset at me for that.
I think his point is that the representation of code is much more complex than you are describing. Take a look at [link|http://java.sun.com/docs/books/vmspec/|http://java.sun.com/docs/books/vmspec/] to see what's involved for Java.
Regards,
John Urberg
|
Post #71,101
12/27/02 3:23:08 PM
|
complexity of Java is not a selling point
That's downright silly. If my "noun model" is originally defined in ER/Win, I'm violating the OnceAndOnlyOnce principle by using it in the database also?
Generally that is only for the initial design. But, it would be nice if they were integrated. If the tool could query the structures and make charts based on that, that would be great. MS-SQL-Server does it more or less (although it crashes often). Many MS-SQL-Server shops have such diagrams from the product all over their walls.
I think his point is that the representation of code is much more complex than you are describing. Take a look at [Java Virtual Machine] to see what's involved for Java.
What is your point? Java being complex is not a selling point. IMO it is too complex. If you have good table/relational tools, you don't need a lot of the crap that Java has IMO. Frankly, I don't know what Static's point is. He does not seem to like me personally, so it does not look like I will get an answer.
________________
oop.ismad.com
|
Post #71,151
12/27/02 8:09:32 PM
|
I wouldn't bother, John.
I shouldn't have replied to him in the first place. He doesn't have any idea how a compiler works, doesn't understand scanning, parsing or lexing and has little idea how a symbol table functions. Small wonder he didn't understand either my descriptions.
Todd actually [link|http://z.iwethey.org/forums/render/content/show?contentid=70915|made my point] much more clearly than I did and the significance of this went right over his head.
Wade.
Microsoft are clearly boiling the frogs.
|
Post #71,163
12/27/02 9:55:00 PM
|
No,YOU don't get it: 1-1-1 is Limiting
He doesn't have any idea how a compiler works, doesn't understand scanning, parsing or lexing and has little idea how a symbol table functions.
That is low level sh8t. I am trying to think above that here. Language parsers generate little data structures, and then uses the stuff in the data structure, not the code. The language itself is for human readability, not the machine's benefit. It is all data structures in the end, not periods and dollar signs.
Todd actually made my point...much more clearly than I did
Well at least you finally admit that your technical articulation skills are full of [biting tonque]. That is a first step.
Todd said: "Look your control tables are just replicating what the OO languages do for you automatically."
Yes, I will agree that it reduces the syntax of 1-way dispatch by about 5%, but bloats up n-way dispatching by far more, and has Meyerian Discontinuity faults (big changes) to go from 1-way dispatching to n-way.
You are bragging about how you can play your one-key piano without hands. That is great, except it can't compete with a 100-key piano using hands.
When all you have is a dictionary, then you start to look at everything thru dictionary-colored glasses. They have been blinded you over time by bad habits. I have liberated myself from dictionary-centric thinking of 1-dimensional OO dispatching and have (a) unlimited keys and (b) unlimited columns and (c) unlimited dispatch results. Your 1-1-1 limits of dictionaries is arbitrary arbitrary arbritray. You just have doing it for so long that you need a patch to quit the habit.
significance of this went right over his head.
The fault is with you, NOT ME! You cannot see the value of going beyond 1-1-1.
(Sigh, why do these discussions always turn out this way? Did *I* start it? Where?)
________________
oop.ismad.com
|
Post #71,191
12/27/02 11:28:16 PM
|
*sigh* Since you asked...
(Sigh, why do these discussions always turn out this way? Did *I* start it? Where?) 1. You made an assertion about how OO worked on some theorectical level. 2. Several people agreed you were on the right track. 3. You made several replies inviting more comment. 4. I replied pointing out that pretty much any language offering classes and objects does what you initially suggested by hiding it in language semantics and automating it for the programmer. (I thought you would get annoyed if I said it like that, by the way.) 5. You replied that I didn't make any sense. 6. I elaborated, citing basic Computer Science fundamentals about compiling, adding on a postscript about a personal point-of-view to programming. 7. You replied to just the postscript. 8. I flamed back. In the Flame Forum, because I wanted to get personal. 9. You responded like you usually do. 10. Still in the Flame Forum, I told you to go learn how a compiler works. 11. You decried that as unimportant information you had no intention of seeking. 12. Two other respondants in this thread began citing basic compiler techniques. 13. I advised one such that you weren't interested in that kind of argument. 14. You got upset. Bryce, the techniques that have been used to write computer language compilers for decades are still being used to implement the vast majority of current programming languages. Whether they are interpreters or compilers, something in between or some wierd combination of both, the techniques and concepts remain the same and are not going to go away. We all brought them up because your initial idea is (to a point) implemented by the compilers and interpreters themselves. It is, as you put it, "low level shit". Go read a book about [link|http://www.amazon.co.uk/exec/obidos/ASIN/0805321667/ref=sr_aps_books_1_1/202-4422159-5690206|how to write a compiler], Bryce. Please. It will help you stop making such a fool of yourself. The fault is with you, NOT ME! You cannot see the value of going beyond 1-1-1. Actually, I can. That was the very point of the postscript. I rarely think of "single-dispatch" versus "multiple-dispatch" because I almost never think of problems in those terms. In the project I code for (it's a web service) there's a function for figuring out a return-to hyperlink. Currently, it is a very long switch statement. I'd like to replace it with something a lot more intelligent and elegant, but that takes time. Currently, when we add another valid return-to type, another few lines gets added to the switch statement. What I want to replace it with would involve adding two or three lines to each page that can be returned to a little bit of information about what parameters have to come back with it (that's the purpose of the switch statement). The return-to logic would then be able to easily figure out the appropriate hyperlink based on that. No switch statement. Instant multiple dispatch. No objects. Well, not unless you want to think of a .PHP file as an "object". Also no database storage or access. Bryce, I can do magic things with 5 and 6 dimensional arrays. I can do nested string manipulations with indices. I scared my boss with my creative use of lists. With some effort and research, I can probably implement a recursive algorithm without recursion. One of those was something a colleague and a very good programmer said was impossible. If an object-oriented solution doesn't work, I will discard it. But if an object-oriented solution does work better than everything else I've tried, then I will keep it. Go learn about how compilers work. Then we will have much better common ground to talk from. Wade. Microsoft are clearly boiling the frogs.
|
Post #71,209
12/28/02 3:41:59 AM
|
shoeboxes, pencils, and strips of paper
I am frustrated because I don't see any way in living hell how compiler implementation has any fricken thing to do with this here, yet you make a big fricken insultive deal about it. It is like talking to the meter maid about differences between two watches and ticket times, and then she suddenly starts to mutter about how the car engine works.
I am *not* talking about machine efficiency here. I am talking about how it makes the life of the *developer* easier and simpler.
Building everything with a dictionary-like class hinders the *developer* because it forces them to funnel everything in their through the concept these "dictionaries". Whether the code is executed through a compiler or a person behind a black curtain using pencils, strips of paper, and shoe-boxes to execute it is moot.
Does your (weird vague) argument still hold if we assume that a person behind a black curtain using pencils, strips of paper, and shoe-boxes executes it?
I doubt it.
You OO'ers just think so weird upstairs. I cannot figure out your odd little minds. It is an intellectual culture clash worse than Middle East fights. Bizzaaar. Yet at the same time it is fascinating, like trying to figure out how aliens think. But the aliens piss in my face when I ask questions.
With some effort and research, I can probably implement a recursive algorithm without recursion.
I have done it using tables. You mark the nodes already visited and process those that are not. You can manage the ordering by sorting by path length and a few other things.
Go learn about how compilers work. Then we will have much better common ground to talk from.
You have not given any evidence that a specific implementation of a compiler is important (beyond performance issues). Whether it is Yacc, gerbals, or pencils and shoeboxes that executes the code is not a concern *at all* to the developers and designers, as long as those all follow the spec. I have no idea why you are bring it up. My schema was meant to be conceptual, not an interpreter design.
12. Two other respondants in this thread began citing basic compiler techniques.
It was a side topic about Smalltalk.
WRT your URL example, I have no idea what you mean by "return-to type". I would probably have to see a little code sample. You know what a fan I am of "type" taxonomies.
7. You replied to just the postscript. 8. I flamed back. In the Flame Forum, because I wanted to get personal.
What "back"? You are admitting that you got personal *first*, accusing me of "deliberately" doing some kind of evil textual act.
________________
oop.ismad.com
|
Post #71,210
12/28/02 4:37:57 AM
|
Read everything again. Yes, the whole thread.
Because I'm not going to say anything I haven't already posted. Meanwhile, I'll try not to annoy you if you'll try not to piss me off. I am *not* talking about machine efficiency here. I am talking about how it makes the life of the *developer* easier and simpler. So am I. I'll say that again: so am I. The implementation details of a specific compiler or language were not mentioned and are not germane to the discussion (though they might be of passing interest). However, there are data processing algorithms common to virtually all language implementations that were. And the one in the spotlight is called a Symbol Table. Building everything with a dictionary-like class hinders the *developer* because it forces them to funnel everything in their through the concept these "dictionaries". Whether the code is executed through a compiler or a person behind a black curtain using pencils, strips of paper, and shoe-boxes to execute it is moot. This is where a grounding in basic computer science would benefit you. If you knew how a conventional compiler worked, you would already realize that your example is inverted. Taxonomy is usually implemented as a specific type of dictionary - called a symbol table - because that is what the language usually needs to achieve what the programmer intended. The namespace characteristics of object-oriented programming came first: dictionaries are the logical ways to implement them down inside the compiler/interpreter. Does your (weird vague) argument still hold if we assume that a person behind a black curtain using pencils, strips of paper, and shoe-boxes executes it? I doubt it. Actually, it would. But I don't want to spend time explaining how right now. Go learn about how compilers work. Then we will have much better common ground to talk from. You have not given any evidence that a specific implementation of a compiler is important (beyond performance issues). Whether it is Yacc, gerbals, or pencils and shoeboxes that executes the code is not a concern *at all* to the developers and designers, as long as those all follow the spec. I have no idea why you are bring it up. My schema was meant to be conceptual, not an interpreter design. I've already told you why I mentioned it: the use of dictionaries to manage type and object names is already in use and is further down in most languages than you think it is. It has nothing to do with a specific implementation. Go learn how a compiler works, already! The book I linked to is very well regarded and covers all the basics and lots more besides. WRT your URL example, I have no idea what you mean by "return-to type". I would probably have to see a little code sample. You know what a fan I am of "type" taxonomies. Let's not go down that road just yet, either. Wade. Microsoft are clearly boiling the frogs.
|
Post #71,228
12/28/02 2:06:39 PM
|
You are still thinking in code
I've already told you why I mentioned it: the use of dictionaries to manage type and object names is already in use and is further down in most languages than you think it is.
It does not matter whether they are already there or not. Tablizing does *not* depend on them for noun modeling because it uses the database and *not* symbol tables nor dictionaries as its higher-level structure. (I suppose you are going to fuss that I should learn how RDBMS are implemented also. Note that one can probably build one using dictionaries of dictionaries if they wanted to. I don't question that.)
I will make you a deal: You go learn about why hierarchical and network databases failed, and I will go learn about compilers.
Sorry I brought the whole thing up. Use whatever fricken definition of OO you want. Mentioning the word "dictionary" apparently triggers rapidly firing memories of your compiler courses, blinding you to my point.
________________
oop.ismad.com
|
Post #70,769
12/25/02 7:44:55 AM
|
Re: A relational definition of OOP
Care to point to some of this guy Martin's screeds?
This definition of OOP in terms of concrete actions and constructions is much better than hand-waving blathering theoretical definitions.
-drl
|
Post #72,951
1/6/03 1:28:47 PM
|
Re: A relational definition of OOP
> Care to point to some of this guy Martin's screeds?
Robert C. Martin, owner, founder, president, and chief bottle washer of ObjectMentor. You can find all kinds of good stuff by going to [link|http://www.objectmentor.com|http://www.objectmentor.com] and clicking on the resources link. Start with the design principles topic or the more general Object Oriented Design.
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
