Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
Prev: Use Case Point Estimation
Next: Association Class
From: topmind on 13 Aug 2005 04:11 Chris Sonnack wrote: > Snipping everything that didn't move this forward shorted it a lot... > > topmind writes: > > >>>>>> Think you can write an SQL query to return a subset of > >>>>>> the records in that table? Of COURSE you can. > >>>>> > >>>>> If it has one table, it is still relational. > >> > >> (This, as stated, is *absolutely* incorrect, BTW.) > > > > Prove it. > > Here's a table (first row headers): > > NAME UID COLOR DATE TYPE > Alice - Blue 5-3-1948 BG45 > Bob - Red 5-3-1948 XL220 > Carol 3345 Red 12-7-1955 E30F > Dave 7709 Green 9-14-2000 - > > I dispute your "relational==table" definition, so I see not > one thing that makes this table "relational". It's just a > (what I'd call) "flat table". Well, my definition is correct. The history of "relational" is based on that usage. Note that "relations" (in a link sense) can be to the same table, such as a table that can represent hierarchies: Name EmployeeID BossRef ---- ---------- ------ Fred 1234 4822 Mike 4838 4822 Jane 4822 5301 ...etc... Here "BossRef" is a foriegn key to the same table. Jane is the boss of Fred and Mike. (I am not necessarily proposing this as a "good" schema, only illustrating self-referencing tables.) > > Given something containing this table that also supported > SQL, you could write: > > Select NAME,COLOR from TABLE order by NAME > > >> Regardless, in the case I had in mind, it wasn't. The > >> question remains: given a flat-table (non-relational) > >> database, can you still write an SQL query. Answer: > >> of course you can. SQL is JUST a query language. > > > > What exactly is a "flat" table? > > See above. Similar to a flat file--an expression I believe I've > seen you use recently. Perhaps I should avoid it if I do. It can have multiple interpretations. > > >>> I am not sure normalization is a requirement for "relational". > >> > >> For the pure (mathematical) definition, I'm pretty sure it's > >> one of the central, defining features! > >> > >> http://en.wikipedia.org/wiki/Database_normalization > > > > I dispute that. > > Okay..... can you support that disputation in any way?? > > The line from that page, "In the relational model, formal > methods exist for quantifying "how normalized" a database is," > seems to suggest to me normalization is a fundamental part of > a relational database. Normalization is simply duplication factoring. The principle exists in just about every code or data organizational principle. In other words, it cuts across paradigms. The principles of normalization as they apply to tables is simply a set of "steps" to help provide or recognize duplication removal. (Normalization levels beyond 3 may not reduce duplication and are controversial.) > > > >>> However, there are different ways to interpret "duplication" for > >>> empty cells. Empty cells do not have to take up physical space, > >>> especially in "dynamic relational". > >> > >> Empty cells? Where did that come from? Are you talking about NULL > >> fields? Row duplication?? What??? > > > > This is getting into a long, drawn out debate about the > > nature of relational. Here is something related: > > > > http://www.c2.com/cgi/wiki?TupleDefinitionDiscussion > > Perhaps related in the sense that other folks (who seem to know what > they're talking about) seem to think you don't. Or related in being > a long, drawn out debate. In the end, I don't think anybody challenged the idea of maps and tuples being representationally equivalent. If they did, they stopped defending it such that their arguments are not supplied. > > But I do NOT see any relation to answering the question I asked. > Can you answer it, or were you just throwing words out randomly? Sorry, but I lost the context of this section of discussion. Please try to provide enough of the original discusion to trigger memories of the context in the future when you trim your replies. I would appreciate that. Use ellipses if necessary. > > >> http://en.wikipedia.org/wiki/Relational_model > >> > >> It starts out, "The fundamental assumption of the relational model is > >> that all data are represented as mathematical relations,..." > >> ^^^^^^^^^ > >> Sounds interconnected to me. > > > > Well, it is misleading. The same link also says: > > > > "A table is an accepted visual representation of a relation; a tuple is > > similar to the concept of row." > > How, exactly, do you think that refutes the first quote? Maybe it doesn't. Either way it does not appear to support your assertation that "relation" means cross-table references in the context of relational. > > > >>>> No, it's a data storage concept. There are many reasons why the > >>>> physical storage location might change. > >>> > >>> Huh? Please clarify. > >> > >> Migration, rollups, new systems, OS changes, format changes, etc., etc. > > > > Yes, but ideally we abstract away from those. For example, we may > > create an ODBC name for a database reference. Even if the machine > > is moved, that same name can still point to the same one. > > If the SAME machine is moved, yes. If the database moves to a different > machine (with a different name, obviously), then no. The ODBC setup > must be tweaked for the new hostname. The ODBC name is not the same thing as a "machine name". It is essentially the name of a configuration, a "reference" to a database (and usually a locally-stored configuration). That way one can refer to just the configuration name in the software instead of having to supply the configuration details themselves in the software. It is abstraction at its best. If you have a better suggestion, I would like to hear it. It is a logical name, NOT a physical name. > > > >> File systems have more flexibility than databases. > > > > Fooey! You already agreed that paths were fragile, being > > hard-to-change. > > I'll accept the "broken path" issue as "cost of business" to gain the > inherent flexibility of a file system any day. I don't break file > paths THAT often--I do use the power of a file system many, many times > every day. Few will dare to overhaul the paths of a large system because of the chaos it causes to existing path references, NOT necessarily because they are satisfied with the tree branching. The paths are essentially primary keys that carry meaning but cannot be changed without heavy disruption. The system grows married to the ugly paths. > > >> Consider this: what happens when several of my files *ARE* databases. > >> Big ones. > > > > I am not sure what you are getting at. > > You want to store files in a database. What happens when those files > are very, very, very large? That is an implimentation detail. There is nothing in relational theory that says "cells must be small". I don't know what the upper limits are on the leading vendor's products. Generally they up the threashold over time. Note that I agree existing RDBMS are probably not up to the task of being file/folder managers. They are not tuned for that use. > > >> Or consider this: in a FS, I can define a folder as publically shared, > >> read-only, and any file I drop in there is available to those I've > >> shared the folder to. I can casually share and unshare files just > >> by moving them in and out of the folder. > > > > I see no reason why a relational system cannot have the same > > kind of thing. However, usually you will find that security > > is not hierarchical as it scales. > > 1. This has NOTHING to do with hierarchical, this is about the idea of > replacing a file system with a database system. > > 2. Describe how you think an RDBMS would provide such a simple service. UPDATE folders SET shared=true WHERE [folder criteria] However, in practice a given folder is rarely best shared with the whole entire world. Thus, some kind of role-based approach or Access Control list may be more appropriate for larger organizations. > > > >> With a database, you can only hope there's an attribute still attached > >> that might turn it up in a query. Maybe so, maybe not. Maybe when > >> Fred took over, he changed the attributes just slightly due to his own > >> personal preferences. > > > > Just because you are not adept at non-tree searches does not mean > > the rest of us are also not. > > Okay, so describe how you would find Bob's old project files after Fred > was done changing the attributes? How is this any worse than changing tree paths to represent the newer changed information? If attributes can lie, then so can tree paths. Either there are sufficient attributes to describe a thing or there are not. If you want to keep a history table for searches based on past attribute settings, you can. (Many RDBMS provide attribute change log options so that one can study the history of something.) It is simply the GIGO principle. Unlike tree paths, adding or removal attributes is usually not going to bust the primary key of a table. Orthogonal info is kept orthogonal. Tree paths don't provide very much orthogonality to attributes. > > > -- > |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | -T-
From: Dmitry A. Kazakov on 13 Aug 2005 04:43 On Fri, 12 Aug 2005 13:22:31 -0500, Chris Sonnack wrote: > Dmitry A. Kazakov writes: > >>> Do you think fuzzy logic is implemented without binary? >> >> Implemented is a wrong word here. Logic isn't implemented. > > Oh. So....er.... those fuzzy logic tools I was using a few years > ago.... were they grown from, like, seeds or raised from pups? (-: Ah, you meant to implement in the sense to use, to be based on. OK. >>> Multi-state logic is built on binary logic. Learn basic information >>> theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it. >> >> No, this is wrong. > > (Has anyone informed Shannon?) Hmm, was Shannon aware of Hilbert's program? I think he was. Anyway in the times after Goedel, we know that there is no way to "break" everything down to 1s and 0s. And even if there were one, neither fuzziness nor randomness can be expressed in a deterministic system without some incomputable elements. The simplest example is: you cannot write a non-pseudo random generator. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 13 Aug 2005 05:03 [snipped 3 pointless insults] > > >> Let's recap. You claimed GUI software--note the term: SOFTWARE--was > >> not hierarchical. I showed you that it was. Then you shifted to talking > >> about GUI usage. > > > > I meant it from the point-of-view of the application developer, and > > not the builder of the tool ("boxed" software). If that was not > > clear, I apologize. > > Once, again, I understood and have been answering that way all along. > The code I showed you was a VB **application** I wrote. VB comes out > of the box. One *can* write hierarhical code in most event-oriented tools similar to how one can write procedural code in most OOP languages if so desired. I don't dispute that. However, just because an event-driven tool allows code or flow to be hierarchical does not make the code itself "event driven". Remember, we are mostly talking about technique here, not tools. > > >> Software--in general--is hierarchically structured. It has high-level > >> routines, mid-level routines and low-level routines. > > > > Not event-driven software (from custom app perspective), at least not > > on the large scale. > > Have you ever actually *written* a GUI application of any size? Are you > under the impression that "event driven software" is JUST event handlers? Mostly event handlers. There may be a few large tasks that resemble batch jobs in their structure, but the majority of the code is just handlers. > > The larger the application, the more it does (besides handle various > events). The more it does, the more it's going to be hierarchical. I don't see why this has to be or should be. > > > The closest thing would be a start-up form, which simply has an attribute > > or reference somewhere marking it as the starting point. > > And you don't think there's start up **code** that sets things up? > You don't think some events result in executing large bits of code? Maybe, maybe not. I don't rely heavily on "startup" events even if they are possible. Like I said before, which form is the startup form can be indicated by attributes or by code (such as a "main") routine. I don't remember which approach VB used, but it does not matter. VB allowed a mix of code styles, not just event-driven. > > Sometimes there's quite a lot of it, in fact. When I launch the > WebSphere App Developer Studio, it takes a couple *minutes* to launch. Because Java and WebSphere suck. Compiled languages often make it harder to load stuff as-needed, forcing one to load everything into RAM up-front. > It's doing a LOT of set up stuff--all (I have no doubt) hierarchically > structured. When I compile all projects in the workspace, it can go > on for several minutes. Again, I'd bet you a year's salary the code > behind the compile is hierarchically structured. It does not matter if the code behind it is girbles on a treadmill. How to write compilers is not the topic here. Just because domain A may use trees does not mean that all other domains should also. That is sloppy extrapolation. Compilers are mostly just "batch jobs", and thus usually will be more hierarhical than the app itself. > > What's gotten lost here is your understanding of the context. What > most of this has been about is the occurrence of trees in nature and > programming. As *data* *structures*, they are natural and vital. Prove it. You have demonstrated that trees tend to be common for lower-level tools {systems software}, but there is still the extrapolation problem to other domains. The fact that you have to keep dipping into the systems software wine for examples raises domain suspicions with regard to your evidence. I don't give a flying slht about how to make compilers and DB indexers. That is not what I do for a living. > > As *taxonomical* structures, you can run into problems, and that's > where the idea of duplicate nodes or cross-branches can be an issue > (albeit, in programming, a solvable one). > > (I think you'd do better if you recognized how important and useful > trees are--particularly as data structures--and didn't try to do the > equivalent of claiming we never landed on the moon. Intelligent > people know we did and that trees do occur in many places in nature > and programming and are terribly useful. That you can only push > your own agenda at the expense of another is--in my book--an almost > certain sign of a kook and a fool.) How about you demonstrate them being universally useful instead of insulting me. Philosphers who have carefully pondered the nature of classification systems have come to conclusions fairly similar to mine. Most developers don't spend a lot of time pondering such stuff, but instead copy the techniques they find in "Learn Foo in 7 Days" books with little thought. Those who actually ponder the nature of structure, hierarchies, and change for a fair number of years will usually agree with me. Tree fans tend to hope that argument-from-authority is good enough. > > > >> Not at all, but it has nothing to do with parse trees. > > > > Then please clarify. I see no need to make a distinction > > between control structures and functions because in some > > languages that are the SAME thing. The other languages > > simply "hard-wire" them into the syntax or lang > > definition. > > Agreed with you last time. Once again, it has nothing to do with > (1) parse trees in general and (2) duplicate nodes in a parse tree, > which (3) IS A PURE TREE (no branches reconnect). by duplicating patterns instead of referencing them. > > >> It still looks like you don't know what a parse tree is, so no. > > > > Whenever you lose and argument, you seem to accuse me of ignorance. > > I don't think I'm losing this argument at all! In fact, I'm quite > sure that, were it being judged purely on its debate points, you'd > have lost it long ago. You are delusional. The duplication of the parse tree node detail is plain as the sky, and you pretend it is not there or that it deserves some special exemption such that your wrong view of the universe is kept intact. Dup is dup. You cannot sweep it under the carpet and ONLY see the tree by ignoring non-tree links/dups. That is cheating, or perhaps evidence you change the picture to fit your world view instead of the other way around. ANY graph can be turned into a tree if dups/CBL's are allowed. Thus, treeing something in itself does not prove that trees are the best tool for managing information. Subroutine calls bust pure trees. That is the facts jacks. > > But regardless of that, I just plain think you ARE ignorant. The feeling is mutual. > > > Prove I am ignorant with details instead of claim it with vague > > accusations. > > The fact that you don't seem to recognize how badly you've lost this > debate or how often I have apparently overwhelmed you with techical > details ought to make it pretty plain that I HAVE proved it. Send me a parse tree from a real program, I will mark up the dup links, scan it to the web, and the whole world can see what a graph it really is. > > > > By the way, here is an example from c2.com wiki: > > Gee, you can copy and paste. Can you *discuss* what you pasted? > > Do you understand why (1) how an "if/else" is implemented is totally > irrelevant, or (2) why a parse tree is a pure tree? Any graph *can* be represented as a "proper tree", but not necessarily a "pure tree". A pure tree has no duplication of nodes or cross-branch links. Most syntax trees of real code are or can be proper trees, but they are usually NOT pure trees. > > > This code: > > [snip] > > Can be represented as a tree: > > [snip] > > Indeed it can. Do you understand what you pasted? By the way, I was the orginal author of that c2 content. > > > >> The code I showed you was developed (by me) as an APPLICATION. > >> As I said last time: > > > > Yes, but I asked for an *event driven* example. That is > > not event-driven, or at least is not the event-driven > > part of the code. > > And, in fact, as a medium-small-sized application, the event-driven > parts are not the bulk part of the application. I showed that to > you to counter your claim that GUI software was not hierarchical. *can be* versus *should be* were addressed above. > > It most certainly is. The event handlers may all exist at the same > level of the hierarchy (although this doesn't have to be true), but > they--if they contain much code at all--will be their own little > hierarchies. I have said many times that on a small scale there are indeed fairly "clean" hierarchies in most code. It is the bigger picture that is at issue. Trees are nice, or at least often acceptable, on the small. I have always agreed with that. > > In fact, here's an example of hierarchy in event-handlers: In some > systems, the main window receives events, which it may process and > return as fully processed or pass on to a child element of the window. > That child element may fully process the event OR pass it in turn to > a child control. > > So there ya go--you're even wrong about events not being tree-shaped. I'm sure there are many ways to jury-rig event-driven tools to have hierarchical features or flow if one is obsessed enough with trees. In general, the "flow" in event-driven designs is determined by actions of the *user*. The user may click in a tree-wise fashion or may not. The point is that the flow is not hard-wired into the code. The more that is hard-wired, the less "event-driven" the design is. > > > -- > |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | -T-
From: Chris Sonnack on 15 Aug 2005 12:35 Dmitry A. Kazakov writes: >>>> Multi-state logic is built on binary logic. Learn basic >>>> information theory. It ALL can be broken down to 1s and 0s. >>>> Every, um, BIT of it. >>> >>> No, this is wrong. >> >> (Has anyone informed Shannon?) > > Hmm, was Shannon aware of Hilbert's program? I think he was. > Anyway in the times after Goedel, we know that there is no > way to "break" everything down to 1s and 0s. Are we possibly talking about two different things here? Yes, Goedel showed we can't fully analyse any non-trivial system, but I believe Shannon hasn't been superceded in the sense that anything that *can* be expressed or computed can be expressed or computed in binary. > And even if there were one, neither fuzziness nor randomness > can be expressed in a deterministic system without some > incomputable elements. But they are incomputable by *any* means, right? > The simplest example is: you cannot write a non-pseudo random > generator. Agreed. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 15 Aug 2005 13:29
topmind writes: >tm> If it has one table, it is still relational. >CS> (This, as stated, is *absolutely* incorrect, BTW.) >>> Prove it. >> >> Here's a table (first row headers): >> >> NAME UID COLOR DATE TYPE >> Alice - Blue 5-3-1948 BG45 >> Bob - Red 5-3-1948 XL220 >> Carol 3345 Red 12-7-1955 E30F >> Dave 7709 Green 9-14-2000 - > Note that "relations" (in a link sense) can be to the > same table, such as a table that can represent hierarchies: > [snip] They *can* be, yes. They can also *not* be. Your initial statement is incorrect *as* *stated*. >> I dispute your "relational==table" definition, so I see not >> one thing that makes this table "relational". It's just a >> (what I'd call) "flat table". > > Well, my definition is correct. The history of > "relational" is based on that usage. Then no doubt you can provide a reference beyond your mere assertion. Even the example you just provided seems to show that it takes a *relation* to be *relational*. >>>> http://en.wikipedia.org/wiki/Database_normalization >>> >>> I dispute that. >> >> Okay..... can you support that disputation in any way?? (Apparently not.) >> The line from that page, "In the relational model, formal >> methods exist for quantifying "how normalized" a database is," >> seems to suggest to me normalization is a fundamental part of >> a relational database. > > Normalization is simply duplication factoring. The principle > exists in just about every code or data organizational > principle. In other words, it cuts across paradigms. But has a very *specific* meaning in relational databases. >> But I do NOT see any relation to answering the question I asked. >> Can you answer it, or were you just throwing words out randomly? > > Sorry, but I lost the context of this section of discussion. No, you didn't. It was IN the post you're replying to. In fact, you quoted it in YOUR post. Here it is again: >You> However, there are different ways to interpret "duplication" for >You> empty cells. Empty cells do not have to take up physical space, >You> especially in "dynamic relational". >Me> Empty cells? Where did that come from? Are you talking about >Me> NULL fields? Row duplication?? What??? >>>> http://en.wikipedia.org/wiki/Relational_model >>>> >>>> It starts out, "The fundamental assumption of the relational >>>> model is that all data are represented as mathematical relations,..." >>>> ^^^^^^^^^ >>>> Sounds interconnected to me. >>> >>> Well, it is misleading. The same link also says: >>> >>> "A table is an accepted visual representation of a relation; a >>> tuple is similar to the concept of row." >> >> How, exactly, do you think that refutes the first quote? > > Maybe it doesn't. Either way it does not appear to support > your assertation that "relation" means cross-table references > in the context of relational. Don't create straw targets. I never said cross-table. But in the interest of moving this along, perhaps there is a problem of lack of precision in words here. By "interconnected" I mean one record referring to another via a foreign key link to a primary key in another record--which, yes, can be in the same table (*typically* not, but that's irrelevant). Where we may still disagree (?) is that, IMO, a "flat table", that is a table with no relationships, is NOT relational. Hence "table" != "relational" >> If the database moves to a different machine (with a different >> name, obviously), then no. The ODBC setup must be tweaked for >> the new hostname. > > The ODBC name is not the same thing as > a "machine name". It is essentially the name of > a configuration, a "reference" to a database (and usually a > locally-stored configuration). Yes. And **IN** that configuration is the machine name. If that changes, the configuration must change. >> You want to store files in a database. What happens when >> those files are very, very, very large? > > That is an implimentation detail. But a very significant one with regard to, um, implementing such a system in the real world. > I don't know what the upper limits are on the leading vendor's > products. Doesn't matter. What happens when I want to store the DB itself in your virtual file system? You can't store a full ten-gallon container inside another ten-gallon container, because there's no room for the container itself. >>>> Or consider this: in a FS, I can define a folder as publically >>>> shared, read-only, and any file I drop in there is available >>>> to those I've shared the folder to. I can casually share and >>>> unshare files just by moving them in and out of the folder. >> >> [...] >> Describe how you think an RDBMS would provide such a simple service. > > UPDATE folders SET shared=true WHERE [folder criteria] You've missed the point. This isn't about how to make a folder shared. It's about the ease of--once having a shared folder--dropping files, or copies of files, into that folder to share them. Or the ease of removing them, or deleting the copies, to unshare them. >>> Just because you are not adept at non-tree searches does not mean >>> the rest of us are also not. >> >> Okay, so describe how you would find Bob's old project files after >> Fred was done changing the attributes? > > How is this any worse than changing tree paths to represent > the newer changed information? Because, as I've said several times before, I can browse around the file system looking for likely folders. (I know this to be true, because I've done it!) I note that, in your reply, you didn't answer my question this time, either. I'll ask it again. Bob's gone, Fred hates him, so he's altered all Bob's attributes. How do you find the project file? -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| |