Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Thu Jul 28 2005 08:09 pm topmind writes: >> That might be the taxonomy, but it's a piss poor OOD. > > It not necessarily about OOD. [...] it was talking about trees in > general, not necessarily related to polymorphism or OO. The context > was about the appearent popularity of trees among computer users > IIRC, not just developers. In fact--as your own task break down showed--it's a natural form for any intelligent person when breaking down something comprised of many parts. Or more properly, of parts and sub-parts...as all tasks are. If all we're talking about is the taxonomy, then one can use as many trees as needed to express different views of the information depending on what one is looking for. If we're talking about programming, then are are elegant ways--as shown in previous posts--to do it. >> What this buys you is the ability to pass around "Drink" objects >> that know what they really are and can behave according to their >> qualities. > > Just like a record from a "Drink" entity. Nope. A record is dumb. It requires code to process it. >> Imagine I have a collection of Drink objects and I want to list >> them in order by the amount of caffeine. simple, since they all >> have a common interface that lets me ask for the caffeine content. > > Just like a record from a "Drink" entity. Nope. Records are dumb. They have no interface. >>>> Here we seem to be talking about tree-shaped *data*,... >> >> ...the larger the scale gets, the more hierarchical **data** is >> a win, simply because you don't have to deal with all the data at >> once. You can pick the scale and branch of interest. > > You are kidding, right? Can you provide that taxonomy of people I > keep asking for? We're talking about **data** here, not taxonomies. (What taxonomy have you 'kept' asking for?) > To not "have do deal with all the data at once", use queries. > We've been over this already. Yes, and it's stupid to query a huge dataset when you can query a much smaller one. >> You KNOW this is true, since you've already agreed that DB indexes >> must use tree structure to speed access to a selected data subset. > > I don't know about "must". Maybe a good non-tree indexing algorithm > has yet to be discovered. Database design is a pretty well-explored domain. There are some very fundamental limitations here. You either need to look at each record to determine if it matches your query, OR you need to--da da--look at a subset....a child of the full dataset. > But that is kind of an internal "mechanical" issue. What works > underneath may not work on the domain level also. When it comes to dealing with large datasets, partitioning is a win. Database designers know this, hence the indexing technology. >> The simple >> fact is, you broke a common task into levels. Just about any set of >> tasks naturally breaks down that way. (In fact, I've spent this week >> working with a project leader for a coming project doing just that. The >> project is very large, and without a hierarchical breakdown, it'd be >> beyond the capacity of any human to deal with.) > > I bet you start to have cycles (or node duplication) past a certain > point. Nope. There are *no* duplicate tasks. Each is distinct. >> And what do you mean by "relational techniques" for file systems? >> Give me an example. > > One could use SQL, another relational query language, and/or > Query-By-Example to find stuff. Not seeing anything "relational" about this. You do understand the term, right? (SQL, for example, works just fine in non-relational databases.) > Take a look at this link for some suggestions: > > http://www.geocities.com/tablizer/sets1.htm Numerical identifiers for folders? Very dumb idea! The example shows: } westsrvr:4251/slides.shw "4251" has no connection to anything real. How can anyone think users can remember "4251"? I have thousands of files in hundreds of directories. No human could remember distinct numbers for all those folders. I can't believe anyone sane could think this was a viable option. Further, all it's done is create an "abbreviation" for a location (but a very difficult abbreviation to remember). The same issue of changes applies. Change the location, and everyone's links are wrong. > I can't speak for everybody, but I would rather have a relationional > file system. I suspect you speak only for yourself. Later on the page is the idea of associating properties to a file and later searching for it by properties. Which is fine until you forget what properties you used, make up too many to handle, or change them. How do you browse through the data to find the lost file?? It also requires a big database in which to store all this. Having worked with virtual file systems that used technology somewhat like this......[shudder] it's a nightmare. >> Why? Show me the structure of a set. > > One generally looks at one *aspect* of a set at a time. In other words, there is no structure. >> It's simple and undeniable: sets have less structure than trees. EOS. > > Prove it! I don't have to, you just admitted it. >> In fact, your thesis depends on this, for one of the main things you >> rail against IS that structure and your perception that it is artificial >> and may not match reality and may be hard to change. Sorry, I don't >> think you can have it both ways. > > Please clarify. Your statement is not clicking in. Your thesis is "trees are bad, because their structure is hard to change. Sets are better, BECAUSE THEY LACK THAT STRUCTURE." Therefore, by your own thesis, sets lack structure (which is true). > Being structured and being easy-to-change may be generally orthogonal. Then why are you so set against trees? They have structure and if ease of change is orthogonal to it.... what's the problem? >>>> A tree is really any structure with a "root" and child nodes. >>> >>> Cross links can cause ambiguous roots and children. >> >> Nonsense. Show me. > > Having 2 bosses in a really small company. Who is the "root"? The CEO. As for two bosses, in the cases I know there is a primary boss and a "dotted line" boss--so called because that's typically exactly how it's shown on the org chart: as a dotted line signifying the secondary relationship. In other cases--and I can speak to this personally, because I was IN this situation for a couple years--each boss had "half" a person. That is, I was 50% allocated to one group and 50% to another. Within each org, I appeared on their org TREE in my proper place with a note that they only got 50% of me. To the point: the situation is *entirely* hierarchical. >>> Interactive software usually has a lot of indirect recursion in my >>> experience. >> >> Are you sure about that? *Recursion* in I/A software? Cite a case. > > A GUI page A where you launch page B, but click a link which opens > another instance of page A. This is common during web-browsing, I would > note. ?? What does browser history have to do with anything? That doesn't in any way speak to recursion in the software. >>> But a pure tree has no duplicate nodes. >> >> That's BS. Show me one authority that agrees. > > Connect the subroutine calls on the paper. Don't take my word for it, > get your pen out. So,... when you can't respond to a point, you just throw in something totally irrelevant? Okay. We'll just assume capitulation. >>> The tree becomes far bigger than the actual thing it is representing >>> because of the duplication. >> >> Totally False. The call tree represents reality. > > And lots of duplications of parts of reality. If a routine is entered multiple times, that **IS** the reality. >> More handwaving. Show me an actual example. I DO event-driven programming, >> and my programs definately have high level routines and low level routines >> (and many medium level routines). > > Show me the hierarchy here in out-line form then. Let's consider the most recent project I've worked on: Main Initialize_Common_Globals() Initialize_Program() Load_Program() LoadProperties() Get_Special_Target_List() LoadList(SpecialTargetList) OpenTable("[SpecialTargets]") Close Load(ApplicationForm) Et cetera. Get the picture? >> My point is your assessment seems unreasonably skewed. You don't >> seem to have the ability to see the situation clearly due to your >> extreme bias and your apparent lack of experience and training. > > Lack of experience? I am a middle-aged developer. Started out on VAX's > and PRIME minicomputers. Time in the saddle doesn't necessarily translate to knowledge. You just don't talk like someone who really understands data structures or OOD or how polymorphism is used. > I used to be more of a tree-fan when I was younger, I would note. > Studying reality changed my viewpoint. My father, an educated man, has come to have some very peculiar ideas in his old age. It's possible your viewpoint is skewed. >> Sets are raw, unstructured data. If you claim otherwise, SHOW ME. > > I don't have a mathematically precise definition of "raw" nor > "unstructured". Do you? I think the definitions of "raw data" and "unstructured data" are pretty clear to anyone who knows what they're talking about. Only someone with no viable response resorts to silly word play. >> Higher: above, superior. >> Order: degree. >> Structure: a complex construction or entity. > > Define "superior". Define "complex". Sounds more like vague sales-talk > or Dilbertian management-speak. If you really don't know the definitions of these basic concepts, how can any opinion you have be worth anything? Alternatively, you do know and have recognized you're in a losing position. My guess is you know what "superior" and "complex" mean. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .