Fine. It is not "bloated". Just unknown.

Post #156,638 by tablizer 5/24/04 1:23:24 PM Reply	Fine. It is not "bloated". Just unknown. User caching: the user information is cached locally, in RAM, for performance reasons. User properties (preferences) aren't loaded unless they're needed. You are micro-managing how to design such an app. Putting the user preferences into a map array may take up far less space and time than your caching manager because cached info takes up space whether you use it later or not. Declarative login checking: if I want to require a user to be logged in to reach a particular screen, I put: <ref bean="loginInterceptor"/> in that section of the config file, and the login is checked and redirected if necessary. So, one could put a "loginOnly()" function at the start of any checked section/page. By not putting it in XML I also have smaller granularity options on where it is used. For example, maybe certain buttons don't show or have a different description if not logged in. Toolkits: Again, if it's not something you can do today, what's the point? I work with today's tools. I get things done. So do I. I have written an e-bay clone (more or less) in less than 7 weeks during the dot-com mayham. When it comes down to it all you have is excuses. You were the one who has been claiming OO is objectively better and then expect me to rewrite a whole Iwethey from scratch? I withdrawl the "bloated" claim for now. Feel better? However, that still does not make OO less bloated than p/r, only unknown. BTW, you guys never countered my running-code toy example at: [link\|http://www.geocities.com/tablizer/chal06.htm\|http://www.geocities...blizer/chal06.htm] I was first with the coded challenge, and now you are trying to trump it with your own. If OO cannot do that better, I would like to know why. If it's because it is a toy example instead of a real one, then describe how it differs from a real one that prevents OO's benefits from showing up. "well, I could code it like this if I had the \ufffdberMegaTOP Toolkit, but we don't, so I'll have to do a crappy job"...? Sure, if they pay me, I will work with lame tools. It may slow me down compared to a good TOP system, but that is life. Same reason we live with Microsoft. I tend to think that favorite paradigms and tools are subjective. Studies by Ed Yourdon seem to suggest that using tools that one is comfortable with is more important for productivity and quality than selecting tools based on what is popular. Show me slam-dunk evidence that OO is better, and I will look into it more. Most reasons given for OO are fuzzy-zenny, and make tradeoffs that the claimers are not aware of or conveniently ignore. For example grouping by noun helps noun-oriented changes, but un-helps task-oriented changes. Plus, the reasons everybody gives why OO is better differ. Some say polymorphism off of "subtypes" or variations is the main power of OO. Others who use more delegation disagree. Nobody has been able to clearly "encapsulate" the benefits of OO. All I get is, "it is j..j..j..just b..b..b..better, and if you were smart like me, you would see it." ________________ oop.ismad.com
Post #156,651 by admin 5/24/04 2:48:18 PM 5/24/04 3:12:45 PM Reply	That's all I needed. You were the one who has been claiming OO is objectively better and then expect me to rewrite a whole Iwethey from scratch? I withdrawl the "bloated" claim for now. Feel better? However, that still does not make OO less bloated than p/r, only unknown. It seems to me the claim under discussion in this thread was "O-R mappers bloat your code". Now that you've admitted that they don't, we can put it to rest. Although I'll note that old habits apparently die hard. You're still weaseling. Either the code is bloated compared to how you would do it, or it isn't. If you're not willing to provide an example, the conclusion to be drawn is "Bryce can't provide an example", not "the status is unknown." You say it's bloated, prove it. Otherwise it isn't. So do I. I have written an e-bay clone (more or less) in less than 7 weeks during the dot-com mayham. Then stop whining about toolkits. You must have used something to do that. BTW, you guys never countered my running-code toy example at: [...] I was first with the coded challenge, and now you are trying to trump it with your own. If OO cannot do that better, I would like to know why. If it's because it is a toy example instead of a real one, then describe how it differs from a real one that prevents OO's benefits from showing up. 1) I'm not in the habit of reading your website in the off-chance that you've provided something for me to do and 2) I'm not interested in toys, which you admit it is. Here's an example that does a real-life thing. If you think you can do better, then have at it. Otherwise shaddap. [edit: removed the broken "challenge" link] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin May 24, 2004, 03:12:45 PM EDT Expand All History
Post #156,657 by ChrisR 5/24/04 2:59:25 PM Reply	Probably not telling you anything you don't already know... ...but that example was originally started by Jim Weirich on Freep's OOP board. JohnU also got involved. Of course, since EZBoard decided to shut down the inactive boards, we don't have any extant to refer to. The reason I like the EZBoard example is (a) it's working (or soon to be working) code - the code can be objectively tested for performance and features; (b) it's something that we share in common and can immediately reap the benefits of any new ideas. So, yes, let's dispense with code fragments and toy code.
Post #156,658 by admin 5/24/04 3:02:11 PM Reply	I take it you mean... ... "IWETHEY example", and not "EZBoard example"? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,659 by ChrisR 5/24/04 3:09:53 PM Reply	Yep = That's what I meant The reporting example was fine, it's just that there was no measurable way to run the code and verify for correctness and performance.
Post #156,695 by JimWeirich 5/24/04 4:55:09 PM Reply	Re: Probably not telling you anything you don't already know ...but that example was originally started by Jim Weirich on Freep's OOP board Actually, the problem was introduced by someone else (JohnU perhaps?). Bryce actually wrote some (non-working) psuedo-code for it. All I did was translate Bryce's non-working psuedo-code into working Ruby code. Then I refactored to a better written procedural version and finally made it more flexible by introducing some polymorphism. I always thought the problem description was a little screwy (I never really understood the need for some the the requirements), but at least we had some form of code from Bryce to compare to. And the OO code compared very favorably with the procedural version (e.g. comparable code sizes (no bloat), polymorphism without taxinomy). At least, that's how I remember it. -- -- Jim Weirich jim@weirichhouse.org [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #156,700 by ChrisR 5/24/04 5:12:43 PM Reply	My memory is too taxed Not sure why I thought you initiated the sample. But your recollection does sound about right. Sure wish we hadn't lost the EZBoard archives. For that matter, I wish Freep would come visit every once in a while.
Post #156,704 by tablizer 5/24/04 5:16:58 PM Reply	Memory Lane I always thought the problem description was a little screwy (I never really understood the need for some the the requirements) We kind of never agreed on the scope. And the OO code compared very favorably with the procedural version (e.g. comparable code sizes (no bloat), polymorphism without taxinomy). If I remember correctly, you implemented a different set of features than mine, so that we really couldn't compare code-to-code for many parts, but rather focused on the architecture issues. ________________ oop.ismad.com
Post #156,686 by tablizer 5/24/04 4:40:18 PM Reply	re: That's all I needed. It seems to me the claim under discussion in this thread was "O-R mappers bloat your code". Now that you've admitted that they don't, we can put it to rest. I didn't say that they don't. I just don't have any comparative evidence to offer youses right now. I am curious though about what percent of self-declared OO proponents prefer O-R mappers. Many have lots of complaints. "Bryce can't provide an example", not "the status is unknown." You say it's bloated, prove it. Otherwise it isn't. False dichotomy. The answer to "is A > B" is Null at this point. Otherwise shaddap. Okay. After addressing some ongoing subissues, I will shut up about O-R mappers until new evidence arises. ________________ oop.ismad.com
Post #156,690 by admin 5/24/04 4:46:37 PM Reply	re: That's all I needed. Given that the evidence so far has either been conceded or unanswered by you, I'd say "isn't" is a lot closer to the current state of affairs than "null". Of course, you will never admit that, so I'll take a "shaddap". I have no doubt that you'll sit on this for a while and then trot out, "youses never proved it wasn't bloated!" at some point in the future, so I'm calling pre-foul now so it doesn't happen. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,652 by admin 5/24/04 2:48:25 PM Reply	Caching You are micro-managing how to design such an app. Putting the user preferences into a map array may take up far less space and time than your caching manager because cached info takes up space whether you use it later or not. The caching manager is generic. I don't need special one-off caching code all over the place. And it seems to me that you've always been the "machines are fast, programmers aren't, optimize for the programmer" champion. Why the sudden reversal? Regardless, I listed it as a feature. If you believe you have a better way of doing it, then do it that way. I'll warn you, though, that the caching speeds the app up considerably over loading it from the database for every request. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,654 by admin 5/24/04 2:48:31 PM Reply	Login checks and declarative processing So, one could put a "loginOnly()" function at the start of any checked section/page. By not putting it in XML I also have smaller granularity options on where it is used. For example, maybe certain buttons don't show or have a different description if not logged in. Which is what my code does in addition to the generic declarative checks. So your method is not as functional. If I want to have the entire application protected, that's one change in the config file. Or perhaps every page that has the word "secure" in the URI. Less work on average. But I don't care how you do it, I'm just telling you what needs to be done. Some pages are protected, others aren't. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,682 by tablizer 5/24/04 4:30:30 PM Reply	re: Login checks and declarative processing If I want to have the entire application protected, that's one change in the config file. In most web apps I have a standard "include" file. If I want the check applied to all pages, I simply put it there. Or perhaps every page that has the word "secure" in the URI. \n // standard header file\n ....\n if (contains(selfURI, 'secure')) {\n performCheckFoo(...)\n }\n ________________ oop.ismad.com
Post #156,687 by admin 5/24/04 4:40:47 PM Reply	re: Login checks and declarative processing And if you decide to move that include file? Or rename it? Don't say it doesn't happen, because it does. What if a developer forgets to include the check file in his page? What if two different clients share the same code, but run it locally and want to configure it differently? Your solutions always "work" for suitably limited scopes. I'll take the solution that's more globally applicable, thank you. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,699 by tablizer 5/24/04 5:11:26 PM Reply	re re: Login checks and declarative processing And if you decide to move that include file? Or rename it? Don't say it doesn't happen, because it does. What if a developer forgets to include the check file in his page? Then most pages will probably not work because a lot of stuff tends to depend on it for things like database handles. What if two different clients share the same code, but run it locally and want to configure it differently? A "split or share" decision is part of any such endevour. Computers can't read minds. If the criteria for triggering a given check changes, we simply change the criteria. Boolean expressions are usually more powerful than subclassing because we don't have to try to cram it into a tree shape and can more easily have orthogonal factors involved. Subclassing tends to puke and squirm when dealing with orthogonal factors. ________________ oop.ismad.com
Post #156,713 by admin 5/24/04 6:01:48 PM Reply	Re: Login checks and declarative processing (new thread) Created as new thread #156712 titled [link\|/forums/render/content/show?contentid=156712\|Re: Login checks and declarative processing] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!