On Mon, 26 Nov 2001 18:24, Leo Sutic wrote: > > -----Original Message----- > > From: Uli Mayring [mailto:[EMAIL PROTECTED] > > Sent: den 26 november 2001 00:42 > > To: Avalon Developers List > > Subject: Re: unsubscribing for now > > > > On Sun, 25 Nov 2001, Stefano Mazzocchi wrote: > > > Keep up the great work and, as a suggestion, avoid flexibility syndrome > > > like the plague :) > > > > To quote Stefano from another posting: > > > > "Flexibility Syndrome is when you add another dimension to your solution > > space to fit a new problem without trying to rotate your previous > > solution space versors to cover the new problem." > > > > I don't know what a "versor" is, neither does my dictionary, but > > probably something like an axis. A less polite way to put it would be > > "change your problem to fit our solution" or "when your only tool is a > > hammer, a lot of problems look like nails" ;-) > > Or, "avoid adding features when you can solve the problem with the existing > feature set."
Or even "avoid solving problem if the problem is too different from intended use that it costs too much in complexity etc" > > Seriously, the world is not just black and white. Everything has its > > advantages and its drawbacks. It seems to me that one of the drawbacks of > > IoC is a loss in flexibility. We all remember the logging discussions :) > > I'd say IoC promotes flexibility like nothing else I've ever seen. As far > as the logging discussions go, I say Berin *restored* IoC in logging by who did that ? ;) > I don't see any drawbacks. The only complaint I've seen is performance > considerations with wrapper classes, but as far as I know, everything other > API have been successfully turned into a Component. Performance has never been an issue for me. The main problem from my perspective is that IOC involves a big investment up front. It will pay off in the long run - if there is a long run. For small projects it easier to hardwire bits together - as long as you know that the small project will never grow ;) > > So far things look good, but > > isn't it a pain in the ass, when you cannot just implement something you > > need because of IoC? :) > > I can not think of anything that would result in not being able to > implement something due to IoC. Basically, IoC is, as someone (forgot name) Pete ;) > stated, about a container H, a component C and a resource R. If H can > intercept C's request for R, we have IoC. -- Cheers, Pete --------------------------------------------------- For every complex problem there is a solution that is simple, neat and wrong --------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
