Post #61,698
11/7/02 4:19:36 PM
11/7/02 9:12:04 PM
|
just recursion there
Who started flaming? I asked you if you had actually tried learning OO
It sounded suspiciously similar to some personal insults from others. If you meant it seriously, then perhaps there are more diplomatic alternatives to asking the same thing. For example, "What is your level of knowledge of OO?"
I've seen you demonstrate some serious ignorance on the subject.
I have been tripped on language-specific trivia and vocab in the past, but never anything *fundimental* to understanding OO itself. (Well OK, Visitor still tosses me, I admit.) May I ask what this alleged big faulup was? Perhaps you are too eager to believe the FUD from those who hold big grudges against me left over from heated arguments.
The reason I asked is because I've seen you try to use tables as the solution to every problem... when all you have is a hammer, everything looks like a nail.
I could say the same about you guys and objects/classes. Objects/classes appear to me nothing more than a crippled collection: a vertical dictionary (hash) array with a search path to optional parent(s) if key is not found in current dict. (The dict keys are the attribute or method name and the value is an attribute value or an algorithm {method} pointer or code.) That is what OO boils down to in my mind.
Dictionaries are fine for simple short-term interfaces, but I would not want to build and manage large-scale structures with them alone. IOW, they are too crippled to serve as a primary building block of everything. Dictionaries have some *arbitrary* limits on them: Only one "match" max, two columns, and one index. This 1,2,1 is an arbitrary set of (low) numbers. They are not universal constants or anything.
IOW, tables make a more open-ended hammer. I am not limited by 1,2,1. I can have a 12,243,17 if I want.
The result of this is that there are many ways to get to a particular object representing one of those entities depending on what the problem you're trying to solve is.
That is what relational queries are like. You give a little relational equation that merges, filters, sorts, etc. the data into just about any organization you can imagine.
Isn't it agreed that relational DB's are better at ad-hoc queries than DB-free OO techniques? Not that ad-hoc queries are the end-all-be-all, but that compact flexibility spills over into the rest of the p/r design also.
I don't want to manage indexes in programming code (as arrays or linked lists, etc.), I want to farm that off to the DB engine. Arrays and linked lists feel too "low level" to me. Plus, it is hard to traverse them without going through the parent's interface first. Some queries don't need the parent.
Trying to do the same thing with a procedural type of program would be a lot more work.
I don't think so. You have nothing but simple recursion here. Besides, some RDBMS, like Oracle, have built-in tree operations so that you don't have to do recursion in your code. (One drawback in the Oracle approach could be different entities at different levels, though. I would have to look at some more specifics of your requirments.)
My designs tend to be less "nesty", so I don't use/need tree-centric operations/algorithms that much (if given a choice). Trees don't scale, IMO. For example, product categories tend to grow non-tree over time because products end up in orthogonal or semi-orthogonal (multiple) categories.
BTW, what is a subpage or subfolder in your setup?
________________
oop.ismad.com
Edited by tablizer
Nov. 7, 2002, 09:12:04 PM EST
just recursion there
Who started flaming? I asked you if you had actually tried learning OO
It sounded suspiciously similar to some personal insults from others. If you meant it seriously, then perhaps there are more diplomatic alternatives to asking the same thing. For example, "What is your level of knowledge of OO?"
I've seen you demonstrate some serious ignorance on the subject.
I have been tripped on language-specific trivia and vocab in the past, but never anything *fundimental* to understanding OO itself. (Well OK, Visitor still tosses me, I admit.) May I ask what this alleged big faulup was? Perhaps you are too eager to believe the FUD from those who hold big grudges against me left over from fat heated matches.
The reason I asked is because I've seen you try to use tables as the solution to every problem... when all you have is a hammer, everything looks like a nail.
I could say the same about you guys and objects/classes. Objects/classes appear to me nothing more than a crippled collection: a vertical dictionary (hash) array with a search path to optional parent(s) if key is not found in current dict. (The dict keys are the attribute or method name and the value is an attribute value or an algorithm {method} pointer or code.) That is what OO boils down to in my mind.
Dictionaries are fine for simple short-term interfaces, but I would not want to build and manage large-scale structures with them alone. IOW, they are too crippled to serve as a primary building block of everything. Dictionaries have some *arbitrary* limits on them: Only one "match" max, two columns, and one index. This 1,2,1 is an arbitrary set of (low) numbers. They are not universal constants or anything.
IOW, tables make a more open-ended hammer. I am not limited by 1,2,1. I can have a 12,243,17 if I want.
The result of this is that there are many ways to get to a particular object representing one of those entities depending on what the problem you're trying to solve is.
That is what relational queries are like. You give a little relational equation that merges, filters, sorts, etc. the data into just about any organization you can imagine.
Isn't it agreed that relational DB's are better at ad-hoc queries than DB-free OO techniques? Not that ad-hoc queries are the end-all-be-all, but that compact flexibility spills over into the rest of the p/r design also.
I don't want to manage indexes in programming code (as arrays or linked lists, etc.), I want to farm that off to the DB engine. Arrays and linked lists feel too "low level" to me. Plus, it is hard to traverse them without going through the parent's interface first. Some queries don't need the parent.
Trying to do the same thing with a procedural type of program would be a lot more work.
I don't think so. You have nothing but simple recursion here. Besides, some RDBMS, like Oracle, have built-in tree operations so that you don't have to do recursion in your code. (One drawback in the Oracle approach could be different entities at different levels, though. I would have to look at some more specifics of your requirments.)
My designs tend to be less "nesty", so I don't use/need tree-centric operations/algorithms that much (if given a choice). Trees don't scale, IMO. For example, product categories tend to grow non-tree over time because products end up in orthogonal or semi-orthogonal (multiple) categories.
BTW, what is a subpage or subfolder in your setup?
________________
oop.ismad.com
|
