Well, with that out of the way...

Post #23,048 by static 1/3/02 6:37:47 PM Reply	Well, with that out of the way... > I see how they function (except in OOVisitor), but I see no maintenance nor code-shortening benefit accept when compared to lame procedural languages and/or lame collection API's. Perhaps you don't at that. I have know programmers who've never understand pointers in C. > May I ask what kind of data caching? I suppose I would have to see your whole app since your design philosophy is probably quite different from mine ground up. The application is a HTTP-based intranet app that looks a lot like a local client (please remember there's a lot of detail I'm not allowed to describe). The code formatting the page and responding to events from the user only needs to know about the data it is dealing with. At a minimum, the caching involves reading the data once from the database in a page-load, and doing that the first time it's needed and no sooner. The logic of that is shared between the generic db_object class (which remember knows how to get data from the database) and the specific sub-class which knows where the data goes. While I think of it, some of the data is built from a table relationship - but the page-rendering code never needs to know this. The DB format was chosen to suit the application as a whole, but the code needs the data in another format. So the object knows how to invisibly do all this for the page code. Without trying to belabour the point, this is one of the advantages to objects. And to respond to an earlier point, most programmers (certainly my colleague and I fall into this category) don't want to think about how the data is stored in the database when we're coding or debugging the page rendering code. We only have to think upto the API provided by the object. > I never used arrays in XBase (accept when that was the only API output choice). However, typical SQL-RDMBS clones don't quite have that same ad-hoc table flavor (option). Bummer. Those are the sort of features that OO hype helped kill off IMO. Instead, it is now assumed that temp state and temp collections go into classes. (However, I here that VB.NET has some of that.) Be careful naming collection types! :-) The term "array" can be quite ambiguous and I should have been more careful. In PHP, an array is a list (sometimes called a "vector") that also has associative lookup. I'm used to both collection types (Icon and SNOBOL have them as standard), just not in the one package. It is one of the things I miss in C. > >> If you intend to go all defensive about classes << > > I just don't get why some seem them as so great. I don't. I suppose I never will. Appearently it is a Zen thing, and not imperical. My apologies. I usually to use classes as custom data types. OOP provides way more power than I usually need, but that's okay: I like the headroom. Many of my objects are simple aggregates of data - like a struct in C - with a few functions for massaging the data. Making such functions methods, in the end, often comes down to mere syntactic differences in calling them. These differences might seen trivial, but when I sometimes want to push the "type" more into an "object" then the choice to had already made to use them as a "class" always pays off. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #23,859 by tablizer 1/11/02 12:40:44 AM Reply	apples to oranges >> Perhaps you don't at that. I have know programmers who've never understand pointers in C. << Not quite what I meant. I DOUBT there are any objective benefits to OOP. IOW, there is nothing to "understand". If it is something real, then it would be demonstratable with metrics like less code, fewer change-points, etc. Zen and objectivity just don't go together, and cause nasty fights. >> don't want to think about how the data is stored in the database when we're coding or debugging the page rendering code. << I have been using DB's for years without worrying about the internal guts of how bits get on disk. You can put yet more abstractions around abstractions, but there is often a point of diminishing returns if not done right, and even a regurgitation toward bloat. ________________ oop.ismad.com
Post #23,868 by static 1/11/02 5:42:43 AM Reply	I'm sorry? Not quite what I meant. I DOUBT there are any objective benefits to OOP. IOW, there is nothing to "understand". If it is something real, then it would be demonstratable with metrics like less code, fewer change-points, etc. Zen and objectivity just don't go together, and cause nasty fights. Now, now. There's no need to be like that. At no point have I been theorizing; all my input has been from recent, real experience. Using objects in the fashion I described has produced a code saving: when I isolated all the DB access into a parent object, there was lots of repetitive and redundant code that could be and was deleted. I could dig out some line-counts from our CVS repository, if you like, though I want to be convinced it would be a good use of my time. I have been using DB's for years without worrying about the internal guts of how bits get on disk. You can put yet more abstractions around abstractions, but there is often a point of diminishing returns if not done right, and even a regurgitation toward bloat. Well, in this case, it is an abstraction that works for us and is thus welcome. There may well be a point of diminishing returns, but we have not reached it yet. And as I've said at least once already, programming with objects works for me and my employer so please stop trying to persuade me otherwise. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #24,061 by tablizer 1/12/02 4:35:39 PM Reply	I don't believe you >> Using objects in the fashion I described has produced a code saving: when I isolated all the DB access into a parent object, there was lots of repetitive and redundant code that could be and was deleted. I could dig out some line-counts from our CVS repository, if you like, though I want to be convinced it would be a good use of my time. << I don't want counts, I want to see the ACTUAL CODE that it allegedly shrunk. Perhaps you are just a bad procedural/relational programmer and that is why it was bloated before. (Or using badly designed API's.) But, I cannot tell unless I see the code. >> programming with objects works for me and my employer so please stop trying to persuade me otherwise. << If you say that it simply fits your neurons better and you personally grok OO better, that is fine by me. However, claims of objective code reduction nuke me up behind the collar. ________________ oop.ismad.com
Post #24,125 by static 1/13/02 4:50:24 AM Reply	"and that is why you fail". I don't want counts, I want to see the ACTUAL CODE that it allegedly shrunk. Perhaps you are just a bad procedural/relational programmer and that is why it was bloated before. (Or using badly designed API's.) But, I cannot tell unless I see the code. I can't show you the ACTUAL code because I would be violating my employment contract. You'll have to believe me when I tell you that I replaced a code sequence in several places somewhat like this: $result = $global_db_handle->query("SELECT * FROM table WHERE table_field == "); if(!$result) exit; $data = []; while( $array = $result->fetch_array() ) $data[$array['table_id']] = $array; $result->done(); With a single call along the lines of this: $result = parent::select($table, $table_id, "*"); And if you won't be satisfied with that example, then there is nothing more I have to say to you on this topic. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #24,194 by tablizer 1/13/02 9:04:46 PM 1/13/02 9:07:53 PM Reply	Looks syntax-heavy to me Pardon me, but isn't: $result = parent::select($table, $table_id, ""); More or less a procedure call? I don't know what the first part of your example is supposed to do because it does not put anything into "result" that I can see. However, it looks like it has a lot more syntax than needed to simply loop thru results. It looks kinda like PHP MYSQL approach, which is a little array-happy. You have waaay too much stuff between the SQL statement and the start of the loop.* I doubt it is usually necessary. I prefer something like: rs = query("select * from bar where x > 5") while getNext(rs) ... print rs.name ... print rs.rank ... // now for some updating ... rs.payRate = rs.yearsOfSrvc * 3 ... saveDB(rs) end while (the middle dot means an associative array. The left dots are because PRE does not work.) In practice, the first line usually looks like: rs = query(stdConn, "select * from bar where x > 5") But if the lang supports named parameters, it could be made to be implied in your wrapper. And if you are just looking for a single value, I have made VBS routines that do: x = queryCell("select * from.........") OR print queryCell("select * from.........") I am not seeing what OOP is allegedly adding. In fact, I am not seeing OOP, period. ________________ oop.ismad.com Edited by tablizer Jan. 13, 2002, 09:06:50 PM EST Edited by tablizer Jan. 13, 2002, 09:07:53 PM EST Expand All History
Post #24,200 by static 1/13/02 10:16:58 PM Reply	I really wonder why I'm doing this. Pardon me, but isn't: $result = parent::select($table, $table_id, "");* More or less a procedure call? Give the man a prize. I don't know what the first part of your example is supposed to do because it does not put anything into "result" that I can see. However, it looks like it has a lot more syntax than needed to simply loop thru results. It looks kinda like PHP MYSQL approach, which is a little array-happy. Then be thankful I didn't show you how you have to do it in C. And $result in the original code is what is called a handle - in this case it refers to a recordset from the designated query. Which I would have thought that was quite obvious. You have waaay too much stuff between the SQL statement and the start of the loop. I doubt it is usually necessary. I prefer something like: Please remember I am using a real language. Theoretical, unimplemented languages are not of use at this point. I am not seeing what OOP is allegedly adding. In fact, I am not seeing OOP, period. That's because I seemed to have over-estimated your conversation skills. Both the original code snippet and the new call are within a member function of the designated objects which then returns the data. Member functions in different objects call the function in the parent class with different tables names passed as parameters, checking first to see if the data has already been retrieved. Page rendering code instantiates the objects as required and calls this member function whenever it wants to be sure the object is populated, without caring what it is called in the database or even what database product it happens to reside in. I believe I've now explained this twice. This was the original direction of your inquiry beginning with "Why sub-class?", wasn't it? Or do I need to revise my estimation of your intelligence still lower? Wade. P.S. Yes, I'm now being insulting. Do not ask why as being called a deliberately ignorant retard often offends. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #24,528 by tablizer 1/15/02 8:43:30 PM Reply	no gap >> Then be thankful I didn't show you how you have to do it in C. << Never was much of a C fan anyhow. >> And $result in the original code is what is called a handle - in this case it refers to a recordset from the designated query. Which I would have thought that was quite obvious. << Your first example has called "done" at the end, which suggests that you are closing it after using it, while the second looks like an instantiation, meaning that you just "opened" it. IOW, they don't appear equivalent. >> Please remember I am using a real language. Theoretical, unimplemented languages are not of use at this point. << Are you saying all that stuff is a necessity???? The minimum needed is one DB-connection handle (usually integer) and one associative array. (In some langs or systems it may be two handles and one associative array.) This is a 2-handle version under a strong-typing viewpoint to clarify (Pascal-like). var ch: integer; // connection handle var rh: integer; // recordset handle var row: associativeArray[]; // may only happen once per program ch := openConnection(.........); ..... rh := openRecordSet(ch, "select * from foo"); while getNext(rh, row) begin ....print("Name:" + row["name"]); ....print("Rank:" + row["rank"]); ....etc. end Are you saying that something like this is impossible to implement? "GetNext" can know the handle of the connection because it knows the handle of "rh" which references "ch" (internally). Where is the alleged gap that you see? I realize that your API's may have a jillion potential options, but that does not mean that you or they could not write wrappers to simplify most of it. (For DB settings, named parameters generally can reduce the call bloat greatly so that every obscure setting does not have to have a parameter position, but often such is not used in order to make the API's inter-language compatible. IOW, the vendor picks the lowest common denominator.) >> I believe I've now explained this twice. << I do not find your description very clear about what exactly you are trying to achieve beyond "populating objects", which can describe just about anything, including sex. If you are able to satisfy vendor requirements based on a single paragraph description, more power to you. >> without caring what ........product it happens to reside in. << That can often be done by wrapping functions (unless you use a feature that a vendor or engine does not support or has a vastly different interface, but this is not a paradigm-specific problem since being polymorphic does not guarantee that every poly will/can be implemented when you swap engines.) ________________ oop.ismad.com
Post #24,570 by static 1/16/02 4:48:47 AM Reply	Yes, there is a gap. I think I've finally figured out why this discussion is not really going anywhere, Bryce. And this time I'm not being insulting. Your programming umm techniques seem to involve snuggling right up to the database. That works in some circumstances: for some application designs and for some data-structures. It is how things like Clarion and XBase worked. Programming takes almost second place to how the data lives in the table(s). However, there are applications where the role of the actual structure of the database is quite quite secondary. The programmer(s) writing the application has no need to know or understand how the data is laid out in the tables, only that when his code needs to get and put it, that it can. Yes, there is a "gap" between the two; something usually called an abstraction or an API. Such a separation may be artificial, due to the mores of whoever has designed it, or it may be a decision encouraged by the tools chosen for development. It may even - and this is quite an important point - be deliberately done by the developers for a number of reasons. In fact, in a large project, such a separation enables multiple people to easily and reasonably cleanly work on their areas of expertise: for instance, the programmer doesn't have to be an expert in database design and the database designer doesn't have to be a UI expert. This "separation" is one of the under-pinning goals of object-oriented programming. Basically, so long as you insist on not having this separation, object-oriented programming will never seem like a good idea and attempts to persuade you otherwise will be fruitless and frustrating for all involved. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #24,791 by tablizer 1/18/02 2:13:21 AM Reply	not just a "mere add-on" >> And this time I'm not being insulting. Your programming umm techniques seem to involve snuggling right up to the database. << Well, I won't argue with that. (Except possibly the meaning of "snuggle", see below.) >> It is how things like Clarion and XBase worked. << I am not really talking about DB-engines embedded into the language itself (although I really seemed to like that). Such is not necessary to rid most of your middle-men structures. >> However, there are applications where the role of the actual structure of the database is quite secondary. << Do you mean that the domain somehow is lacking the need for flexible collections, or some sort of hardware speed constraint? I view tables no more as "just an add-on" than youses view OOP as a mere "add-on". I don't just talk to them, I surf on them. >> The programmer(s) writing the application has no need to know or understand how the data is laid out in the tables, only that when his code needs to get and put it, that it can. << To me, tables are the most flexible collection interface technique known. If the relationships and views of things are likely to grow or morph, then it is hard to beat a relational table interface. I notice that many people try to use code to model the domain and relationships between things. I much prefer tables and relational algebra. It is like specifying a formula for a repeating pattern instead of physically repeating the pattern itself. More compact and easier to change. It can be almost likened to using the Manderbolt (sp?) equations instead of carrying around a jillion GIF's. >> In fact, in a large project, such a separation enables multiple people to easily and reasonably cleanly work on their areas of expertise: for instance, the programmer doesn't have to be an expert in database design and the database designer doesn't have to be a UI expert. This "separation" is one of the under-pinning goals of object-oriented programming. << I don't see how OOP helps this. A division between an application programmer and DBA (RDBMS) is quite common. In some cases the programmer only has to call stored procedures and never touch SQL syntax (but I do not necessarily always agree with that technique). I am not sure what you mean by "UI Expert" here. UI API builder? Application interface designer? Application interface programmer? P/R offers division of code by "tasks". I have yet to see how OOP makes cleaner and more consistent divisions than this. One can walk into most P/R shops, look at the DB schema and task (module) names, and within half-an-hour or so have a fairly good forest-level view of the application. OOP is harder for this because there is no consistency from one OO guru to another. You don't have the world-wide code-by-tasks-DB-for-entities division consistency that P/R has in OOP. Further, the bad habit of excessive protocol-coupling found in many OOP designs is yet another grokability and manageability fault. Just because the implementation is hidden away is no guarantee that the interfaces are not messes. Managing interfaces is just as important to software manageability. >> Basically, so long as you insist on not having this separation, object-oriented programming will never seem like a good idea and attempts to persuade you otherwise will be fruitless and frustrating for all involved. << I just don't find code a good place to manage high-level complexity and repetition from. OOP is too code-centric IOW. My head can grok and manage better when control and relationship information is factored into tables. I find them more compact, more concise, sort-able, filterable, and multi-viewable than code structures. (Fancy IDE's try to approach this in proprietary ways, but still have problems factoring out repeated packaging of items. They are just poorly trying to reinvent the collection management wheel already perfected by relational tables.) Tablizing control information makes it lean, mean, and clean IMO (relative). If your neurons work better under different information management and representation arrangements than mine, that is fine. Just don't try to extrapolate that onto me. After all these years I know what the hell my head likes WRT org techniques more than you ever can, because you are not me. (I am sure you are relieved about that fact.) ________________ oop.ismad.com
Post #24,621 by Arkadiy 1/16/02 2:08:06 PM Reply	I think I see what's going on... (oh, why am I doing it...) You say that you use 2 integers: var ch: integer; // connection handle var rh: integer; // recordset handle And then you say: ""GetNext" can know the handle of the connection because it knows the handle of "rh" which references "ch" (internally)." Now, _integers_ do not have any internals. There has to be something behind those "integers" to hold the connection. And therein lies the reason why all Bryce vs OOP discussions have been so pointless. Bryce, you are _scripting_ objects. The things that your pseudocode operates on are objects. You work at JavaScript level. At that level, objects are rarely useful. But, when you have to implement things that are behind ch and rh, objects come in handy.
Post #24,792 by tablizer 1/18/02 2:21:47 AM Reply	handles == pointers or ID's to bigger things >> Now, _integers_ do not have any internals. There has to be something behind those "integers" to hold the connection. And therein lies the reason why all Bryce vs OOP discussions have been so pointless. Bryce, you are _scripting_ objects. The things that your pseudocode operates on are objects. You work at JavaScript level. At that level, objects are rarely useful. But, when you have to implement things that are behind ch and rh, objects come in handy. << Handles are simply ID's. They point to some structure, table, record, object, desk, or whatever. IOW, "rh" points to something that contains the value or address of "ch". Scripting has nothing to do with it. An ID is an ID. A simple integer (or string) is sufficient to hold one. From the API user's perspective, it does not matter what that handle references. It does not matter if it points to an object or a gerbil; for that is hidden (abstracted away) for the API user's benefit. The concept existed long before Simula-67. Even if OOP (allegedly) helps implement those internals, it is not shown to be a helper for the user of the API. I don't build table engines for a living, so I don't know that side of things well enough to really comment on OOP's help there. I am mostly viewing this from an application developer's perspective. What is good for the goose may not be good for the gander (especially those tampons, they poke sensitive things). I don't believe in one-language/paradigm-fits-all. (I suppose strong-typed languages may protect the API user from using the wrong handle with the wrong API in some circumstances.) ________________ oop.ismad.com
Post #24,870 by Arkadiy 1/18/02 7:50:51 PM Reply	Looks like we're in agreement.
Post #24,887 by tablizer 1/18/02 11:21:01 PM Reply	So "OOP is of little or no use for custom biz apps" I don't think others here agree with that assertation. They are usually of the "OO is good everywhere" mindset. If they have changed, it is news to me. Otherwise, now they will start throwing rocks at you. Your turn at the crusafix. ________________ oop.ismad.com
Post #24,893 by static 1/19/02 5:20:54 AM Reply	No, that part is incorrect. One major part that makes OO useful is that if GetNext is a method of the object DataBaseHandle, then the compiler ensures that you can only call GetNext with a DataBaseHandle. If GetNext is a conventional function being based an opaque handle, then GetNext can only check at run-time that it is being based a DataBaseHandle. It doesn't sound like much of an advantage, but it is. And interpreted languages are another case entirely that I don't think we'd better tackle here and now. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #24,925 by tablizer 1/19/02 2:10:22 PM Reply	re: compile-time protection >> It doesn't sound like much of an advantage, but it is. << No, I don't see that a signif advantage. Those kinds of errors are not the problems that hog the most debug time IME. Waiting for run-time to find out you are using the wrong handle is a very minor issue in the vast majority of cases. Regardless, I don't really care that much whether I use "handle.action" or "action(handle)". The ideal API would use the default connection handle automatically anyhow, so that there are fewer handles to confuse to begin with for most calls. If everybody thot like me when they design crap, the world would simply just work smoother. (Stop choking please.) Further, I prefer interpreted environments (perhaps with a Lint-like utility for some early warning.) If I was forced into OOP, I would probably go with Smalltalk or Python than Java or Eiffle or OOPascal (marketability being the same). Thus, haven't given much thot to strong-typed or compile-protection-happy T.O.P. ________________ oop.ismad.com
Post #24,943 by static 1/20/02 4:34:38 AM Reply	Go away, Bryce. You asked - politely, I might add - about using objects and classes and I answered. And it turns you don't (still) like the answers. I stand by them. I don't know you well enough to know if you get some perverse enjoyment out of this type of discussion, but I generally don't. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #25,047 by tablizer 1/21/02 11:25:24 PM Reply	Okay, but first I have to get the last word in >> And it turns you don't (still) like the answers << Becuase you are comparing OOP to CRAPPY P/R. If you compare the tram to a Yugo, of course people are gonna take the tram. That extra middlemen arrays and stuff between the query and your loop is UNNECESSARY, yet you were quick to use it to hype up OOP. Garbage reasoning like that simply reinforces my view of how delusional some OO fans are. >> I stand by them << Then you are unreachable and irrational in my book. And a sh8tty procedural programmer at that. YOUR EVIDENCE SUCKED ________________ oop.ismad.com
Post #25,049 by folkert 1/21/02 11:35:52 PM Reply	Oh my... Bryce you are an Oxymoron. `greg, curley95@attbi.com -- REMEMBER ED CURRY!!!` In 2002, everyone will discover that everyone else is using linux. Linux: Good, fast AND cheap. Failure is not an option: It comes bundled with Windows. ** "Two rules to success in life: 1. Don't tell people everything you know." - Sassan Tat
Post #25,198 by Arkadiy 1/22/02 7:24:45 PM Reply	The king of OOP is typeless (that would be Smalltalk, of course). OOP is first and foremost a way to organize info in your head. It existed before the invention of "objects" in the form of APIs and handles. Of course, using _real_ OO language helps to make it easier, but, just like a concept of procedure existed before Fortran, the concept of "object" existed before Simula or C++. It just was not called that way.
Post #25,482 by tablizer 1/24/02 12:49:40 PM Reply	I agree with your premise, but.... >> The king of OOP is typeless (that would be Smalltalk, of course) << I didn't say otherwise. I would note that Smalltalk lacks certain protections of the typed OOPL's IIRC. As long as the message names match, it generally ain't care. >> OOP is first and foremost a way to organize info in your head << Some OO fans may dispute this. They may say it reduces actual change work (maintenance effort) by reducing the average number of different spots that need changing. However, I would also note that every head is different. Tables are easier for me to grok than code. Thus, the more control and management info factored into tables, the easier it is for me to grok not only the structure, but the control contents themselves. >> Of course, using _real_ OO language helps to make it easier << The "easier" part excapes me. Nobody can externally isolate it, instead telling me to just try it for 7 years and will eventually "click". >> the concept of "object" existed before Simula or C++. It just was not called that way. << In my view, some zealots got carried away with certain "cute" ideas and made languages around such extremism. For example, the flexibility of has-a overrides any minor code savings from the "automatic dispatching" of polymorphism (is-a) IMO. IOW, has-a has a lower cost of "degeneration" away from mutually-exclusive divisions by sub-categories. (I know, not all polymorphism requires that, but the vast majority of it in modeling does.) ________________ oop.ismad.com
Post #25,784 by Arkadiy 1/25/02 6:17:30 PM Reply	People's brains are different indeed >>>>>>>>>>>>>> In my view, some zealots got carried away with certain "cute" ideas and made languages around such extremism. <<<<<<<<<<<<<< Or, to tone down the language, some people created languages to suit the way they thought. Other people created Lisp. Turns out, "Code is data" does not mean self-modified code. I recently found that it means something else, much deeper: you can actually store/present your data as code, to a point that dictionary data structure needs no data at all, it's just a function. Still other people created Prolog. Give me logical constraints, and I will create a solution that satisfies them. Or a few solutions. May be in a second, may be in a week. But most people think in terms of "things" doing something to other "things". Hence the popularity of OOP. As long as there is one big "thing" doing everything in the code, you don't need it. When you have more than 1 - sorry, can't escape it. Whether you call things "objects" or not. You, apparently, dont think in such terms. I'd like to know how you think. Long rambling "stream of consciousness" about a programming problem would be appreciated.
Post #25,880 by tablizer 1/26/02 2:45:22 PM Reply	head survey? >> Or, to tone down the language, some people created languages to suit the way they thought. << I think every language is like this for the most part. A universal metric has never been found (or at least agreed on). >> I recently found that it means something else, much deeper: you can actually store/present your data as code, to a point that dictionary data structure needs no data at all, it's just a function. << Perhaps. However, I lean more toward "code as data" rather than "data as code". Tables give a 2D view of information relationships, whereas code gives a mostly 1D view. >> But most people think in terms of "things" doing something to other "things". Hence the popularity of OOP. << I won't dispute that some people indeed think that way, however, I question your suggestions of commonality. Many hard-core OO fans often complain that most programmers "keep slipping and slidding back to procedural", suggesting that the guts of these "slackers" are really procedural, or at least mixed. >> You, apparently, dont think in such terms. I'd like to know how you think. Long rambling "stream of consciousness" about a programming problem would be appreciated. << Isn't that how you guys characterize my website? :-) I just seem to grok controlling information better as tables than as programming code for the most part. Tables are like the rolls of punched paper in player pianos: you don't have to grok how the piano works to see the tune. A flag will say, "I do feature X", but you don't have to bathe in the details about how feature X is implemented right then and there. The simple "what" is not mixed into the complex "how". Doing such drags them both down. >> As long as there is one big "thing" doing everything in the code, you don't need it. When you have more than 1 - sorry, can't escape it. Whether you call things "objects" or not. << This seems to be saying that OOP is "better partitioned" than p/r. I dispute that. Things are divided by "tasks" in code (and entities in the db). No matter how huge the app/system is, each task can be considered relatively independantly. Plus, you don't get near the protocol coupling as you often do in OOP IMO. The tables are the large-scale glue and not code, and tables are easier to grok than code. ________________ oop.ismad.com
Post #25,905 by wharris2 1/26/02 9:15:26 PM Reply	Re: head survey? I've been told my head was unusually large and gave my mother problems at birth. Oh, wrong topic. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #25,918 by tablizer 1/27/02 12:03:16 AM Reply	Is that why she walks funny? :-) ________________ oop.ismad.com
Post #25,923 by static 1/27/02 12:27:18 AM Reply	Here's an idea for you. I just seem to grok controlling information better as tables than as programming code for the most part. Tables are like the rolls of punched paper in player pianos: you don't have to grok how the piano works to see the tune. You have an advantage on me, then. I can't read piano roll notation. I tried it in a sequencer several years ago; nup, couldn't do it. So I found another sequencer that works entirely in manuscrupt. So I suggest you might want to be more upfront about not grasping OO thinking. A hot "I can't understand it, so it sucks!" is rather less effective than a "I'm sorry, I don't get it - no, don't bother explaining, it's okay" or an "It still doesn't really make sense; have I got this bit right? ___", depending on what you're fishing for. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #25,954 by tablizer 1/27/02 3:49:17 PM Reply	how != why >> You have an advantage on me, then. I can't read piano roll notation. I tried it in a sequencer several years ago; nup, couldn't do it. So I found another sequencer that works entirely in manuscrupt. << I made a custom MIDI sequencer based on tablization and "piano-roll" views: [link\|http://geocities.com/tablizer/foxmusic.htm\|http://geocities.co...foxmusic.htm] >> So I suggest you might want to be more upfront about not grasping OO thinking...."...have I got this bit right?..." << I am not quite sure what you mean. There are two different issues here: 1. Understanding how an OOP program works. 2. Understanding why it is "better". #1 is generally not the problem (aside from OO-Visitor, but it is not used much in practice anyhow.) The more I tried studying it, #2 did not improve at all. If anything, I found more stupid justifications for OOP in the books. Something is either wrong with 95% of all OOP authors, or something is wrong with OOP. The second is the most likely. BTW, does anybody here want to defend Meyer's "panel" thingy in OOSC2? To sell me, I would have to see some good examples of OOP business applications side-by-side with decent p/r versions, and a detailed account of why the OOP version is better using things such as change impact analysis. ________________ oop.ismad.com
Post #26,165 by Arkadiy 1/28/02 6:27:13 PM Reply	Getting inside your head... What I'd love to see is a demonstration of a solution for a problem that you'd encounter in your code. Not solution itself, even. How you thought to arrive at the solution. For example, in OO I often say to myself: "This bunch of functions looks like an object interface. Time to introduce another object". Or, "I don't know how to divide responcibilities here, I don't understand who does what to whom. Am I missing an important actor?" That's the kind of dialog I'd like to see here, but done your way.
Post #26,178 by admin 1/28/02 7:51:03 PM Reply	Maybe in a new thread though... ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #26,196 by tablizer 1/28/02 9:16:43 PM Reply	(I moved discussion to Flame Quarantine area) ________________ oop.ismad.com
Post #26,197 by admin 1/28/02 9:33:25 PM Reply	Not necessary... Everyone has been pretty civil so far (other than coughChristiancough). Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #24,907 by folkert 1/19/02 11:11:32 AM Reply	AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH <rhetorical> Does he ever STOP??? </rhetorical> <factual> It's been what... 6 years now??? </factual> <emote> Rolls eyes </emote> <result>`if [ -z tablizer_post or [ -r tablizer_post and -k tablizer_post ] ] then set TABLIZER_IGNORE = 1 export TAB_DISPLAY=/dev/null fi` </result> `greg, curley95@attbi.com -- REMEMBER ED CURRY!!!` In 2002, everyone will discover that everyone else is using linux. Linux: Good, fast AND cheap. Failure is not an option: It comes bundled with Windows. ** "Two rules to success in life: 1. Don't tell people everything you know." - Sassan Tat
Post #24,931 by tablizer 1/19/02 2:55:43 PM Reply	answers: no, 3, whatever, chicken! ________________ oop.ismad.com
Post #24,937 by folkert 1/19/02 10:32:02 PM Reply	You missed the meaning again... Same as always... Since we were still at forums.infoworld.com. You started pretty early, no later than early 1997. It read like this: If in testing your post being (-z) zero length of tangible text OR it is (-r)readable and you are being (-k)sticky, then set the IGNORE bit and any further display to goto the bit-bucket. Sorry, had to explain that for you. I am sure others picked it up... Have a nice day! `greg, curley95@attbi.com -- REMEMBER ED CURRY!!!` In 2002, everyone will discover that everyone else is using linux. Linux: Good, fast AND cheap. Failure is not an option: It comes bundled with Windows. ** "Two rules to success in life: 1. Don't tell people everything you know." - Sassan Tat
Post #25,045 by tablizer 1/21/02 11:15:21 PM Reply	I prefer readable scripting languages ________________ oop.ismad.com
Post #25,048 by folkert 1/21/02 11:32:08 PM Reply	Then you cannot know... how to program as those were just the easy bits, called Shell Scripting, one of the MOST basic of all scripting "languages". Best part is: I made them with the modified syntax just to make it easier for people (with a brain) to read. And you still failed!!! **CHUCKLE Bryce, sometimes you just kill me...with your stupiidity. `greg, curley95@attbi.com -- REMEMBER ED CURRY!!!` In 2002, everyone will discover that everyone else is using linux. Linux: Good, fast AND cheap. Failure is not an option: It comes bundled with Windows. "Two rules to success in life: 1. Don't tell people everything you know." - Sassan Tat
Post #25,492 by tablizer 1/24/02 1:09:18 PM Reply	Give me tools that fit the way I think and I can..... ....program circles around you OO zealots. BTW, if your scripting tools are so "easy", then how come it takes a jillions lines just to get and loop thru a query result???? Perhaps "easy to fubar" an otherwise simple program. ________________ oop.ismad.com
Post #25,671 by hnick 1/25/02 7:55:18 AM Reply	Heh! Certainly one possibility... The other, of course is to get someone who is flexible enough to use existing tools for their strengths in particular tasks. Feel free to disagree as to which is easier to implement... -Hugh
Post #25,755 by tablizer 1/25/02 4:01:07 PM Reply	jack of all trades, master of none >> The other, of course is to get someone who is flexible enough to use existing tools for their strengths in particular tasks. Feel free to disagree as to which is easier to implement... << My observation is that there is a general tradeoff. Even God does not give out free lunches. Some can fairly easily shuttle among paradigms and always be "adaquate". Others will be wizzes in one tool/paradigm type, and lackluster at others. As an experiment, I would like to force CRC to use Smalltalk and Jay to use Delphi. (Sure, there may be a few that master and shine in all, but those are a minority. Besides, most programming is dealing with goofy users and PHB BS politics rather than raw development anyhow.) ________________ oop.ismad.com
Post #25,824 by hnick 1/26/02 12:24:15 AM Reply	That would be me, kinda sorta... I have never been in one situation long enough to be, by my standards, an absolute master of any technology. I do provide always a respectable product, as on time as possible, in budget as is possible. Often, much of the project circumstances are beyond my control. I live with it. I started doing Intel assembler. Got kinda good at 8080/85 coding. Switched to PLM/86 when 8088's became popular. Learned C because I was tasked with producing libc for PLM. Used DOS 2.11 boxes as cheap development machines. Did embedded stuff using C with PC's as development platforms (cheap again.)Did protocol converters (honeywell dps-6/8) in DOS, then ported to unix (Sun NEWS and X), os2, and windows in that order. Went to Diebold, where I mucked about with DB/2, getting into databases (os/2), and later another place where I got to do proprietary DB work, but the Seimens stuff used KSH, the Solaris stuff used SH, and the rest of the fuckwits used MS Windows in flavors. Mostly C. Learned a lot of scripting and fell in love with perl. Tilly's undoubtedly better than me at perl, but that makes my code no worse... Now, I'm back to doing driver and low-level utility work for Windows again (C/C++). I've got no religion on this. I don't like MS but I've got a wife and puppies to feed and this is arguably more genteel than shoveling shit. I may not be a master at any one given field, but I give good value if I'm hired. I do good designs, and I hit my numbers if not fucked with too much. I can work with whatever tools I am provided with, although I am not above making suggestions that would make my life easier. This is the point that you miss... the focus is the project, not you. Some projects can profit from OO; others can't afford the overhead. If you can't get your mind around OO, find slimmer projects or legacy projects. You might want to find somewhere that you work well rather than forcing others to fit your limitations (CRC aint gonna bite anyway.) Cheers, Hugh (almost a master of a bunch of stuff...)
Post #25,688 by CRConrad 1/25/02 9:20:59 AM Reply	There are NO tools that can make a 3-yo moron a watchmaker. Some crafts just take skills that not all people have, and no tools -- however advanced or "fit the way I think" -- can give them those. Which of these phenomena do you think I think you are an example of...? Christian R. Conrad The Man Who Knows Fucking Everything
Post #25,759 by tablizer 1/25/02 4:15:50 PM Reply	My apps can kick your apps butt, neener neener ________________ oop.ismad.com
Post #25,959 by folkert 1/27/02 4:33:59 PM Reply	OUCH... No recovery Possible Bryce.... `greg, curley95@attbi.com -- REMEMBER ED CURRY!!!` In 2002, everyone will discover that everyone else is using linux. Linux: Good, fast AND cheap. Failure is not an option: It comes bundled with Windows. ** "Two rules to success in life: 1. Don't tell people everything you know." - Sassan Tat
Post #60,539 by boxley 10/31/02 8:10:13 PM Reply	Ive cut my trees ate my lunch now where is the newspaper? will work for cash and other incentives [link\|http://home.tampabay.rr.com/boxley/resume/Resume.html\|skill set] "Therefore, by objective standards, the leading managers of the U.S. economy...are collectively, clinically insane." Lyndon LaRouche
Post #25,689 by boxley 1/25/02 9:25:44 AM Reply	ask and you shall receive [link\|http://www.jes.com/pb/\|non oop tool] thanx, bill My Dreams aren't as empty as my conscience seems to be
Post #25,758 by tablizer 1/25/02 4:12:32 PM Reply	Seems a little weak in the relational department although I wonder if there are SQL hooks for it now? And numerical subroutine names don't look very fun either. If you are gonna stick me in the past, then stick me with XBase or PL/SQL or something. It interestingly does seem to be fairly type-free though, almost like Perl. ________________ oop.ismad.com
Post #25,941 by CRConrad 1/27/02 9:48:51 AM Reply	Too bad, ya gotta stick with Xbase only. Hadn't you heard? -- PL/SQL went OO too, a couple years ago or so. Christian R. Conrad The Man Who Knows Fucking Everything
Post #25,944 by admin 1/27/02 10:10:50 AM Reply	Laf, hardly. Not until 9i is PL/SQL something that can be called more than remotely OO. Having objects doesn't make something OO. :-) 8i's object relational features are pretty bad. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #25,990 by tablizer 1/27/02 10:06:49 PM Reply	tells u what the 2 richest men in the world think of OO ;-) ________________ oop.ismad.com
Post #60,562 by CRConrad 11/1/02 4:22:15 AM Reply	Yeah, but Sssshhhh! El Adminoman: Not until 9i is PL/SQL something that can be called more than remotely OO. Having objects doesn't make something OO. :-) 8i's object relational features are pretty bad. You don't think Bryce knew that before you told him, do you? Go undermining my argument like that -- just because it's a little bogus... Sheesh! ;^> [With thanks to the BOx for reviving the thread... Or NOT! :-] Christian R. Conrad Microsoft is a true reflection of Bill Gates' personality - the sleaziest, most unethical, ugliest little rat's ass the world has seen unto this time. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=42971\|Andrew Grygus]
Post #25,955 by tablizer 1/27/02 3:57:48 PM Reply	what hazn't? >> Hadn't you heard? -- PL/SQL went OO too, a couple years ago or so. << Almost anything that is still alive stuck some OOP-ish features in in order to appear modern on PHB feature checklists. A powerful fad that OO. All the XBase's added classes, etc. also. That was disappointing because they could have easily tablized everything. FoxPro even went away from tablizing its GUI setups. Note that Oracle Forms can tablize it's GUI's I hear. More on that at the slow ezboard. ________________ oop.ismad.com
Post #25,197 by Arkadiy 1/22/02 7:20:29 PM 1/22/02 7:21:26 PM Reply	OOP is no use for relatively small apps. OOP is of little of no use when you write stuff at JavaScript level. And even in that case, youend up calling metods, even if you call object "handles". On the other hand, in a large project there happens a point where your own data structures/code become as complex as underlying DB access code/data. So, if you agree that OO is good for writing "those internals", you may consider usong OO for your own code, as it grows as complex as "internals". As long as you can manage w/o "handles" (objects) and APIs (member functions) - fine, keep on using procs. Edited by Arkadiy Jan. 22, 2002, 07:21:26 PM EST Expand All History
Post #25,490 by tablizer 1/24/02 1:03:36 PM Reply	on scalability >> And even in that case, you end up calling metods, even if you call object "handles". << Taking credit for handles is going al gOOre overboard. A handle is simply an ID that points to a larger thingy. That is as much a database concept as it is OOP. >> On the other hand, in a large project there happens a point where your own data structures/code become as complex as underlying DB access code/data. << IMO, the p/r model is more scalable for these reasons (at least): 1. One focuses generally on one task at a time, regardless of the project size. 2. Tables and large ER setups are easier to grok than large class networks. (Usually a lower protocol-coupling ratio also). 3. P/r tends to factor common patterns into tables instead of code structures, where non-programmers or newbies can manage the control info without ever touching code. The Report Manager example is a case in point: most new reports are simply specified with data in tables. OTOH, most OOP puts all that info in code, where attributes and algorithms are all mixed together in a hard-to-navigate soup. ADMIN: is there an area we can take these battles so that they don't "clutter" the regular stuff? I know that some of you don't like these kind of discussions. Thus, if they can be moved to a dark corner somewhere, they may not bother you as much. ________________ oop.ismad.com
Post #25,782 by Arkadiy 1/25/02 5:45:04 PM Reply	Thingy Here is a challenge for you. Try to explain what a handle points to without using a word that is a sinonym of "object". WRT taking credit: I am not. I am actually saying that handles and APIs have a lot to do with the appearnce of OOP idea. The idea of object was somewhat derived from them. And then, it turned out, the better is an API written, the easier it fits into that new approach (better in a sence that existed _before_ objects). WRT scalability: I've never said that there are no other good approaches that scale up. I am just saying that OOP does not scale down quite as well.
Post #25,883 by tablizer 1/26/02 2:55:23 PM Reply	All Your Nouns Are Belong To Us >> Here is a challenge for you. Try to explain what a handle points to without using a word that is a sinonym of "object". << That is a little hard since any noun could be called an "object". Every paradigm deals with nouns, just differently. OOP simply tends to group and focus on them more than others. Its philosophy is that Nouns is King. IOW, it does not just "have" nouns, it elevates them. But the practicality of it is that I don't know what handles point to in most cases. It could be pointing to gerbals on treadmills powering the database. That implimentation detail is abstracted away such that the app developer does not have to worry about that when they use the handle. Perhaps OOP implements gerbals better, but that won't help the handle user because they don't see the basement. ________________ oop.ismad.com
Post #25,924 by static 1/27/02 12:28:52 AM Reply	How very interesting. He almost gets it, Arkadiy... Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #25,956 by tablizer 1/27/02 4:10:45 PM Reply	And youses can almost articulate the benefits >> He almost gets it, Arkadiy... << The only thing solid you have come up with is that some OOP langs can protect against the wrong ID (handle) being used on the wrong entity/object/gerbal/thingy. There are ways to do such without OOP if it was really a signficant issue. Is that the best you can do? It does not extrapolate into the "dynamically typed" OOP langs. Does that mean we should toss those? Jay is gonna be sad. Rasberries for all ________________ oop.ismad.com
Post #24,073 by wharris2 1/12/02 6:13:59 PM Reply	You can't reason with many people about many things. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #24,117 by tablizer 1/13/02 12:55:19 AM Reply	the p/r api's are either fixable or not If they are not fixable (shortenable), then I am wrong and youses win. (However, since he probably programs very differently than me, it might be comparing apples to oranges and the entire app would have to be compared rather than just parts.) ________________ oop.ismad.com

Welcome to IWETHEY!