Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Fri Aug 12 2005 07:14 pm topmind writes: >> Your inability to answer a simple set theory question indicates you >> don't know set theory. That's fine. Just checking. End of story. > > You are trying to use social intimidation instead of facts to back your > points. You find it intimidating being asked to demonstrate that you know what you're talking about? How sad. >>>> So, you bumped the issue up to a higher level and let them work out >>>> which of THEM had a higher priority for your time. In other words, >>>> it was *entirely* hierarchical. >>> >>> Being "higher" is not necessarily hierarchical. Jet "A" may be higher >>> than Jet "B" in the sky, but that does not necessarily imply that the >>> placement of jets is hierarchical, for example. >> >> Jets in they sky don't have a relationship. Bosses and employees do. > > So trees are about *social* relationships??? Don't be willfully stupid, there are many types of relationships. I'd think someone hot for RELATIONAL databases would understand that. >> Hierarchies *are* about relationships, and like it or not, the world >> is *filled* with them. > > Relationships, yes. Trees, no. Fine. You can open an office between the Flat Earth Society and those twits that think we didn't *really* go to the moon. >> 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. >> 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? The larger the application, the more it does (besides handle various events). The more it does, the more it's going to be hierarchical. > 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? 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. 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. >>>You> But a pure tree has no duplicate nodes. >> >>>Me> Show me one authority that agrees. >> >> I don't know how to make the question plainer. > > [..yet another non-answer...] Fine, whatever. Obviously you can't cite a single authority, and for good reason. No part of the definition--even of formal trees-- prohibits duplicate nodes. > [big snip] 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. 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.) >> 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). >> 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. But regardless of that, I just plain think you ARE ignorant. > 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. > 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? > This code: > [snip] > Can be represented as a tree: > [snip] Indeed it can. Do you understand what you pasted? >> 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. 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. 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. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .